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ABSTRACT 

Current methods of system reliability analysis cannot easily evaluate 
the time dependent availability of complex dynamic systems. Improved methods 
are needed to treat such issues as process variables, feedback, and rule 
based Interactions between components . 

A dynamic Monte Carlo system availability simulation model is 
developed. The basic model, called DYMCAM, is based on three fundamental 
modeling objectives. First, to provide the ability to analyze time -dependent 
availability of dynamic systems. Second, to provide a model which is easy 
to apply and interpret. And third, to create a model which can easily be 
modified to incorporate additional features as needed. The output generated 
by the program includes time -dependent system unavailability information and 
average system unavailability over the duration of the simulated time period. 

The DYMCAM model is tested on several basic availability analysis 
problems to demonstrate program capabilities. These tests include a single 
component with exponential failure and repair times, a single component with 
two repair states, a two -out -of- three pump failure system, and a phased 
mission problem requiring the forced change of a system component state after 
the start of the analysis. A modification of the DYMCAM program was also 
developed to demonstrate the capability of treating continuous process 
variables in a dynamic simulation model. 

Results of all test were compared with analytical results where 
possible, and with Markovian analysis techniques in other cases. The 
simulation model provided accurate unavailability results on all example 
problems tested. Further work needs to be done to expand the capabilities 
of the basic DYMCAM model and to continue program testing on more complex 
problems . 
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Chapter 1 
Introduction 

1.1 Foreword 

The Engineering community has always depended upon the methods of 
system reliability evaluation and prediction to solve practical engineering 
problems. The use of all engineered structures and inventions is dependent 
upon their ability to perform to some predetermined specifications. Thus as 
technology advances and systems become more complex it becomes necessary to 
derive new and better ways to ensure the reliability of such systems. 

Recent examples provide abundant evidence of the need for proper 
attention to reliability analysis in engineering design. One prominent case 
is the failure of a seal on the booster rocket for the space shuttle 
Challenger in January of 1986, which lead to the deaths of five astronauts 
and a three year delay in the NASA space shuttle program. In the nuclear 
industry, the failure of a pressure operated relief valve to reseat can be 
argued to be at least partially the cause for the melt down of the core of 
the unit 2 reactor at Three Mile Island in March 1979. And there are many 
other such events in all engineering disciplines which indicate dramatically 
the results of engineering systems which have not performed adequately. 

The field of reliability analysis has continued to meet the challenge 
in the increasingly complex technology of today's society. Over the past two 
decades many advances have been made in all areas of system analysis and 
progress continues to be made. To meet the needs of future technological 
advances and to provide for the highest possible levels of safety and 
reliability in all aspects of engineering it is necessary for systems 
reliability analysts to continue to improve the state of the art by 
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identifying and developing new analysis and prediction techniques. 

1.2 Baclcground 

Today many approaches and methods are employed in the process of system 
reliability analysis. For single components which are mass produced and 
essentially identical, fundamental probability laws are applied to estimate 
the probability of any given component functioning correctly for a specified 
number of hours. This estimate is made based on historical performance of 
identical component and engineering judgement about any improvements which 
may have been made. 

For systems made of many components, fault trees or event trees may be 
used to calculate static system reliability characteristics as described in 
references D-1, M-1, and P-1. From these trees, minimal cut sets are 
identified which can be evaluated numerically to provide failure rate 
information for the system. For complex systems where it is necessary to 
determine all combinations of conditions which may lead to a specified 
deviation of a system parameter, digraph methods may be used as discussed in 
reference K-1. Then fault tree synthesis methods may be used to construct 
fault trees from the digraph. 

For repairable systems with exponential repair and failure rates, 
Markovian analysis may be used to compute time dependent system availability 
and unavailability as delineated in references M-1, P-1, and G-2. Markov 
systems may be solved explicitly using Laplace transforms, they may be solved 
by computing eigenvalues and eigenvectors, or they may be solved by computer 
numerical integration techniques. Through use of Chapman -Kolmogorov 
equations it is possible to determine the probability of transition between 
any two system states given that the probabilities of all intermediate 



transitions are known. 
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The current methods available can be characterized as belonging to one 
of two major categories. These are static reliability analysis methods, and 
dynamic methods. The former are useful in determining system reliability at 
a specified instant of time. The later give time dependent system 
information in either discrete or continuous form. Static methods can give 
detailed information about a system at a specific time point, but are often 
not useful in evaluating dynamic systems. Dynamic methods give solutions to 
time dependent problems, but are often difficult to apply. A simulation 
model for dynamic system unavailability analysis can be developed which 
allows for easy construction and interpretation of complex dynamic 
reliability problems. Such a model could explicitly model interactions 
between components and include any desired capabilities such as various 
component repair states and testing and maintenance modeling features. There 
is a need for such a dynamic simulation model which can easily analyze 
complex systems and has the adaptability to be easily modified to handle a 
wide variety of problems (e.g., non- exponential transition times, dependent 
component failures, and control system reliability problems involving 
continuous process variables) . 

1.3 Organization of this Work 

The purpose of this work is to propose a simulation model for dynamic 
system availability analysis. In Chapter 2 a survey is performed of the 
current techniques being employed in system reliability analysis. Their 
applications and limitations are addressed. 

In Chapter 3 simulation languages are discussed briefly along with the 
specific characteristics of SIMSCRIPT II. 5 which is being used for this 
simulation model. Program objectives are examined and all assumptions made 
are explained. The chapter concludes with a complete description of the 
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dyncunic simulation model. 

In Chapter 4 tests are performed on the simulation program and results 
are compared with selected established methods to demonstrate the program's 
validity. The procedures against which the model is compared include the GO- 
FLOW method and Markov chain techniques. 

Chapter 5 presents a modification to the program to demonstrate the 
capability to model continuous variables. Specifically, the model is altered 
to perform the storage tank problem analyzed by Aldemir in ref. A-1 and ref. 
A- 2. Results are compared with a Markovian analysis and the predictions of 
ref. A-1. 

In Chapter 6 the results obtained with this model are summarized. The 
flexibility and adaptability of the simulation model are discussed along with 
limitations. The dynamic simulation model is compared with other reliability 
analysis techniques and their relative strengths and weaknesses cited. The 
chapter concludes with recommendations for future work. 
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Chapter 2 

A Survey of Current System Reliability Analysis Techniques 

2.1 Introduction 

In this chapter a review is done of some of the current methods for 
reliability analysis. The literature has been surveyed and papers selected 
representing a cross section of the state of the art in reliability 
assessment. For ease of discussion these papers have been divided into two 
general areas under which all reliability analysis work can be categorized. 
These are static reliability analysis tools and dynamic system evaluation 
techniques . 

In the following sections the current trends in both techniques are 
considered by reviewing recent literature. Figure 2.1 indicates the 
reliability analysis methods to be discussed and their categorization. 
Examples are used to illustrate unique features of the various procedures, 
and where appropriate, weaknesses in the methods are pointed out which could 
be avoided by using a dynamic simulation analysis approach. The chapter 
concludes with a summary section. 

2.2 Static Methods 
2.2.1 Fault Trees 

One of the most familiar models used in system reliability analysis is 
the fault tree, described in reference W-1. The fault tree is a static 
system evaluation tool since it applies only to calculating the system 
reliability at a specified instant of time. To calculate dynamic information 
involves stepping forward in time and re-evaluating the tree. 

Fault tree analysis is a deductive approach to system analysis and is 
used to compute the probability of an undesirable event, such as the non- 
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Figure 2.1 System RelieOsility Analysis Methods 
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operation of a system. The fault tree is a logic structure indicating how 
combinations of basic failure events can lead to the undesirable event of 
interest. The fault tree is then used to assess the probability that a 
system of components will be in a particular discrete state at a given point 
in time. 

All fault tree analysis methods use a minimum of three logic operators. 
These are the AND gate, the OR gate, and the basic event or component, which 
has a set of failure data associated with it. Basic events in the tree refer 
to faults. 

The methodology of fault tree construction consists of three steps. 
Step one is to identify the system to be analyzed and what boundaries are to 
be imposed. Step two is to determine the terminal failure event. This is 
the "top event" to be evaluated. And step three is to work backwards through 
the system to the component level to determine which combinations of 
component failures lead to system failure. This third step involves 
generating the logic structure known as the fault tree. Once the fault tree 
has been constructed, a boolean algebra expression can be written and solved 
numerically for the probability of the top event given the failure data 
concerning the individual components. Automated fault tree construction is 
possible using the CAT computer code as discussed by Apostolakis in reference 
A-4. 

Consider the example shown in Figure 2.2A. The system consists of 
three valves which are supplied with flow from source A. Failure of the 
system is defined as occurring when flow is not present at point B. All 
three valves are normally open. In step one of constructing a fault tree for 
this system, the boundaries of the system are defined as the flow source A 
and the flow sink B. The second step is to determine the undesired event 
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Valve 1 




b.) Fault Tree 



P(No Flow to B) ■ P(No Flow at A) ♦ P(Valve 3 closed) 

+ (P(Valve 1 closed)*P(Valve 2 closed)) 



c,) Boolean Expression 



Figure 2.2 Fault Tree Example Problem 
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which for this example is loss of flow at point B. The third step is to 
identify which combinations of event can lead to the "top event." For this 
simple system, there will be no flow at B if valve three fails closed, if 
valves one and two fail closed, or if there is no flow from the source A, 
The fault tree can be constructed by tracing backwards from point B. Figure 
2 . 2B shows the fault tree for the example . 

Based on the Boolean logic expressed by the fault tree, an expression 
can be written which quantifies the probability of the top event occurring. 
For the example, an approximate version of this expression is shown in Figure 
2.2C. This expression can be evaluated numerically if the probabilities of 
all basic events are known. For complicated systems, computer codes are 
available which quantify the tree automatically. 

Fault tree methods evaluate only the probability of a system being in 
a specified state at a given time, thus they do not directly apply to dynamic 
problems. But by thoughtful construction of a fault tree, and by evaluating 
the tree over and over again it is possible to treat dynamic problems in a 
discrete fashion. Repair and failure cycles can even be considered. 
Important limitations do exist, however. For instance, consider the example 
of Figure 2.3. The system is composed of two pumps providing flow to point 
A. Failure of the system occurs if flow is not provided by at least one of 
the two pumps, both of which are normally operating. If the failure rate of 
each pump depends on how many cycles of repair and failure it has been 
through, a fault tree of the system will be very clumsy (there will be a 
branch for each possible cycle) . Thus a fault tree is not well suited for 
such a problem. 

A variation on the fault tree method is described in reference D-2 by 
Dhillon and Rayapati . This method is similar to fault tree techniques but 
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Pump 2 
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a.) Diagram 




b.) System Fault Tree 




c.) Component Fault Tree 

Figure 2.3 Fault Tree Limitation Example 
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involves systems composed of three state devices in series, parallel, series - 
parallel, and bridge configurations of any complexity. Any system which can 
be modeled in this fashion can be simplified through a series of reduction 
steps to a single equivalent three state component representing the entire 
system. This method assumes independence of all components. 

Since a three state component is simply a model of a component which 
can fail open (on) or closed (off) and must be in one of these two failed 
states, or operational, it is clear that a fault tree can be constructed to 
model the same system and identical results would be obtained. The authors 
suggest this approach as possibly being of beneficial use to practical minded 
reliability engineers because of its simplicity and ease of use on 
appropriate problems. 

2.2.2 60 Methodology 

Another approach which solves for static system reliability is the GO 
methodology which was developed in the mid-1960's by Kaman Sciences 
Corporation. It gives results similar to fault tree evaluation computer 
codes, but differs significantly in its approach and structure. References 
G-1 and B-1 describe the GO procedures and a modified GO approach 
respectively. 

The GO methodology is a "success oriented" technique which uses an 
inductive approach to determine the probability of a system being in a 
specified state. The procedure combines component probabilities and 
interactions to produce the probabilities of preselected output events. A 
set of standardized operators is available which are used to model all of 
the physical components in the system. Components are then linked using 
signals which represent the probability that the system is operational up to 
that point in the system diagram. This resulting GO chart in many cases 
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closely resembles a schematic diagram of the physical system layout. 

There are seventeen basic operators in the GO method designed to 
incorporate the majority of logic functions found in physical system 
components. These operators include the three logic operators comprising the 
fault tree code methods plus fourteen additional ones which provide the 
capability to model the logic of most physical components with a single 
operator. Figure 2.4 shows the GO operators and is taken directly from 
reference G-1. For components which are not readily modeled by a simple 
operator it is possible to create a "supertype" which is a compilation of 
several operators to model a given component. This supertype can then be used 
to model the given component at every place it appears in the system. The 
object being to generate a GO chart model whose components very closely 
resemble the actual system components and operation. 

The method of GO analysis consists of six basic steps. First, the 
system to be analyzed must be defined and all necessary information such as 
schematics, system description, success criteria, logic diagrams, and 
operating procedures must be gathered. Second, all inputs and outputs from 
the system, and each individual component must be determined and 
interrelated. A system may have many inputs and outputs unlike the fault 
tree method which has one output, the terminal event. To solve an identical 
problem using fault tree methods, several separate fault trees must be drawn. 
Third, a functional GO chart is drawn which indicates which components are 
dependent and which are independent operators. Fourth, each operator on the 
functional GO chart is assigned a type from one of the seventeen basic 
operators. Fifth, each operator is assigned a kind number so that if several 
valves in the system are identical, the failure data may be entered once for 
that "kind" of valve. Finally, the signal sequence must be identified so 
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Figure 2.4 GO Operators’ 



From Reference G-1 page 2-3. 
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that when the program runs the logical flow of the information in the model 
will be the same as the actual system. 

The GO approach forces the analyst to begin the modelling process after 
defining system boundaries by inductively progressing from input to output 
by modelling the functional relationships between hardware components to get 
a successful input event to an output event. The basic events in the model 
are thus hardware components . Each component or operator , depending on its 
type, may exist in a variety of states, ie. open, closed, failed, failed 
prematurely, etc. This allows the model to more closely resemble actual 
system operation. 

All signals existing in a GO analysis are numbers representing 
probabilities of existence of physical quantities, including flows, voltages, 
actuation signals, etc. Thus all signals have values between zero and one. 
When the GO program is run the logic operators operate on the signals in much 
the same fashion as the fault tree codes to produce the final output signal 
strength. The output or outputs will have values between zero and one 
indicating the probability of occurrence of the output event. 

Figure 2.5A shows a schematic diagram of an example system containing 
a fluid source, two pumps, two check valves, and a remote operated valve. 
This system is modeled with GO operators in Figure 2.5B. The operators in 
the GO chart contain numbers indicating which type of GO operator is being 
used. The second number inside some of the operator symbols corresponds to 
the specific "kind" of operator. For example, operator number 6 is used to 
model both the two pumps and the motor operated valve. The two pumps are 
identical and are therefore assigned the same "kind" number, which in this 
case is 2. The valve is assigned a "kind" number of 4. When the GO program 
is executed, an input file is used which provides failure data for each 
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separate operator "kind" . 

It is readily seen from this example that the GO chart provides a 
system representation which very much resembles the physical plant layout. 
The model shows all components of the system and shows the relationships 
between them. The signals between components are numbered indicating the 
order in which system analysis progresses. Thus the GO method allows for 
time sequencing of events but does not provide dynamic availability 
information. Once a GO chart is created and an appropriate input file 
generated for computer evaluation, results are calculated in a manner very 
similar to fault tree analysis. The GO program will find and quantify all 
cutsets of the system, and print the minimal cutsets, if desired. The final 
result provided for the example of Figure 2.5 would indicate the probability 
of flow existing at point C at a specified instant of time. As with fault 
tree methods, to compute the system reliability at another time point will 
require a separate run of the program with a modified input file to reflect 
the new component failure probabilities. 

The modified GO method proposed by Billinton and Patwardhan in 
reference B-1 presents simple changes to the original GO model. Since the 
basic GO method assumes independence of series elements, Billinton and 
Patwardhan point out that the method can lead to severe underestimation of 
the system reliability. The modification proposes using equivalent 
components to replace the individual components in a series systefn thereby 
incorporating the concept of dependence into series networks. The results 
are important for systems in which the failure of one series element does not 
prevent the subsequent failure of another element in the series while the 
first is under repair. Numerical examples Illustrate the difference in 
results obtained from the two approaches. Both concepts are useful tools in 
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Figure 2.5 GO Example Problem 
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analyzing repairable systems. 

2.3 Dynamic Methods 
2.3.1 Event Trees 

Event trees are an inductive logic method used to identify the various 
possible outcomes of a given initiating event. The initiating event is 
normally some type of system component failure event or it could be an event 
external to the system. Event trees step through the possible consequences 
of the initiating event, and thus can be thought of as a quasi -djmamic 
reliability analysis tool since the passage of time is required between 
successive events in the event tree. 

To illustrate the use of event trees, consider the example of Figure 
2.6 which is taken from reference M-1. The example wishes to determine the 
probability of release or radioactivity from a nuclear reactor resulting from 
a large loss of coolant accident. The first step in event tree analysis is 
to identify the initiating event. For the example the initiating event is 
a large pipe break. The next step is to identify all applicable systems 
which may effect the outcome of the event. For the example, these are 
electric power availability, ECCS availability, fission product removal 
system availability, and containment integrity. The order in which these 
systems should appear in the event tree will depend on the logical 
relationship between them. Note that these logical relationships may 
conflict with the temporal sequence of events. For example, if the ECCS 
system depends partially on the availability of electricity, then electric 
power should come first in the event tree. In some problems, the order may 
be unimportant if systems are unrelated. 

After all applicable systems are determined, then the success and 
failure states for each system must be determined. With this information. 
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b.) Reduced Event Tree 

Figure 2 . 6 Event Tree Excunple^ 



Taken from Reference M-1 page 195. 
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the tree of Figure 2,6A can be drawn representing all basic events. Some of 
the sequences shown may not be physically possible due to timing constraints 
and sequential and conditional dependencies, thus the next step is to 
eliminate the impossible states. The end result will be the reduced fault 
tree shown in Figure 2.6B. Each branch represent a possible outcome as a 
result of the initiating event. Each branch is quantified based on the 
transfer probabilities indicated. Determination of these individual transfer 
probabilities may involve the use of fault tree diagrams. 

The example shows that event trees can be used in a limited sense to 
evaluate dynamic problems. The method requires that all system states be 
determined before quantification of the final state probabilities in much the 
same fashion as fault tree analysis. Once the event tree is identified and 
all transfer probabilities determined, calculation of terminal probabilities 
is straightforward and involves only simple multiplication as indicated in 
Figure 2.6. The major drawback of the event tree method is that it can not 
treat systems which contain loops. For example, in Figure 2.6, if the EGGS 
system fails and is then repaired it is desireable to transfer to another 
branch of the event tree. This can not be done without including a separate 
branch from the EGGS failed condition, which can certainly be done. However, 
if the problem to be analyzed contains an infinite possibility of component 
repair and failure cycles , the corresponding event tree must contain an 
infinite number of branches. This is not practical and thus limits the 
applicability of the event tree method to those systems which do not contain 
loops leading back to an event condition through which the analysis has 
already passed. 

2.3.2 Digraphs 

The method of digraphs is a tool used for analyzing relationships in 
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complex systems in which the desired operational state of one component may 
depend on the actual state of another component in the system or upon the 
level of a system process variable. These types of interactions are 
characteristic of all process control problems, and digraphs are a useful 
tool for analyzing causes of abnormal events in these systems. For example, 
a control system may monitor the level of fluid in a storage tank which 
supplies water to several different sources. Assume there are three pumps 
which can provide fluid input to the tank, and that the number of pumps 
operating at a given instant of time depends on the fluid level of the tank. 
If the tank is nearly empty, then all three pumps may be required to be on, 
while if the tank is almost full, only one, or none of the pumps may be 
required. A digraph analysis of this problem will treat the interaction of 
the fluid level causing pumps to turn on and off in a cause and effect type 
manner. 

Reference K-1 by Kohda and Henley gives a detailed description of a 
digraph method. A digraph is a structure consisting of nodes and edges. 
Nodes represent process variables, or certain types of failure events and 
edges indicate a relation between two connected node variables. A digraph 
will resemble actual system configuration and can be easily constructed from 
a flowsheet of the process to be analyzed and a schematic diagram of the 
equipment. Fault trees are directly s 3 mthesized from digraphs and then 
analysis continues in the same manner as for fault tree methods. The 
additional capability is that the digraphs are designed to treat continuously 
variable processes. This procedure is ideally suited for process control 
type problems where component states depend on the value of a continuously 
varying signal, and where there is a need to determine the likelihood of 
deviating from steady state by a given amount. Results of the analysis 
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provide information on the probability that the system is in a given state 
at specified discrete time points. However, Kohda and Henley state in ref. 
K-1 that, in their view, none of the automated fault tree construction 
methods available, including the new one they propose, are successful in 
providing complete, consistent, and correct failure modes without human 
intervention and judgement. Thus the method of digraphs may involve 
considerable work to construct the digraph and then compose an appropriate 
fault tree. 

Digraphs are a useful tool for identifying the minimal combinations of 
disturbance conditions which can lead to a specified undesirable condition 
at a digraph node. This is especially useful for optimizing control system 
design. The method includes dynamic system considerations, as the sequencing 
of component and process interactions must be considered when constructing 
the digraph. The analysis results obtained are not a dynamic representation 
of the system unavailability, but rather a listing of disturbances which can 
lead to undesirable performance of the system being analyzed. The method of 
digraphs requires complete knowledge of system behavior before analysis can 
begin, so that all possible system disturbance modes are identified and 
included in the digraph analysis. 

2.3.3 GO-FLOW Methodology 

Developed by Matsuoka and Kobayashi, the GO-FLOW method was generated 
in the mid-1980's as a success-oriented system analysis technique to analyze 
the time dependent unavailability of phased mission problems. References 
M-2 and M-3 give a detailed description of the method, philosophy, and 
structure as well as several illustrative examples. 

The GO- FLOW methodology is derived from the GO code and is therefore 
similar to it in many respects. The GO- FLOW method uses an inductive 
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approach and a combination of ten basic operators to create a GO-FLOW chart 
which very much resembles a schematic diagram of the system being modeled. 
The GO-FlOW operators are shown in Figure 2.7, which is taken from reference 
M-2. Table 2.1, also taken from reference M-2 summarizes the output 
relationships for each of the operator types. The idea is to create a 
reliability model which can be easily understood by the design engineer. The 
modeling process for GO-FLOW is much the same as for the GO methodology. 

The GO-FLOW chart will look similar to a GO chart except for the fact 
that there are fewer basic operators available in the GO-FLOW method. All 
GO-FLOW operators have corresponding operators in the GO code but the 
operation of each is slightly different. Each of the seven additional 
operators used by the GO code can be modeled using combinations of the other 
basic operators in the GO-FLOW code. 

The major difference between the two methods is the manner in which 
signals between operators are treated. The signals in a GO model correspond 
to the probability that a component is in a given state independent of time. 
Thus, a time dependent system analysis cannot be performed. Signals can go 
from "on" to "off" or vice versa but they can not go from "on" to "off" and 
then back to "on." Thus it is not directly possible to incorporate repair 
in a GO model. In a GO-FLOW model, on the other hand, many signals represent 
probabilities, but they are functions of discrete time points. Some signals 
represent only time information to cause proper activation of time dependent 
operators at the proper instant during the process of the analysis. Thus a 
GO-FLOW model, unlike the GO model, is time dependent. The GO model 
incorporates time sequencing in its analysis but the GO-FLOW method simulates 
the actual passage of time through discrete time steps. Signals in a GO 
model indicate a change of state or an occurrence whereas in the GO-FLOW 
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Figure 2.7 GO-FLOW Operators^ 



Taken from Reference M-2 page 66. 
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TcUsle 2.1 

Summary of the Function of GO-FLOW Operators^ 



Operator 

Type 


Main Input Signal 
Intensity 


Subinput Signal 
Intensity 


Output Signal Intensity 


21 


S(f) 


— 


R{D =SU)P, 


22 


S,(r).S;(f) SAD 


... 


Probability that at least one input signal exists 


25 


... 


... 


Probability of a demand or time duration 


26 


S(r) 


PU) 


R{t) = S(r) O(0, 0(r,) = P^. 
0(1) =0(f') + l\.0-OUD]P(DP, 


27 


SU) 


PU) 


R(D =S(i) 0{D. 0((,) = 1.0- P^, 
0(0 = O(f')(I.0-P(f)-P,J 


30 


S, in. SAD 5,(0 


... 


Probability that all the input signals exist 


35 


S(f,).S(f2) 5(f) 


P,UD pad) 

PiUD Pi(D) 


RiD =S(f) exp|-Xi: D P,(o)/m/j[1.0.S(o)/5(f)lj 


37 


5(f) 


PAh).--..PAD) 
PiDD PAD) 


R(D =S(0-exp[^-Xi: E /’.(O)] 


38 


5(f) 


PAD) PAD) 

PzUD.--.PAD) 


P(f) =S(f) |l.O-expj^-XT; V p,(,,)|j 


39 


5(f) 


P\U) 

PAD 


R(i) = SU)O(r). 

0(1) = 0(f) + (I.O - 0(f)\P\(D-P„ 

R(t) =S(t) OU). 0(1) =O(f') |1.0- PAD-PA 



Taken from Reference M-2 page 67. 
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model signals represent time dependent component state information. This is 
the major point of difference between GO- FLOW and its predecessor. 

With this time capability GO-FLOW has the additional potential of being 
able to perform an unavailability analysis incorporating repair in the model. 
To do a time dependent analysis with the GO code would require several runs 
of the program and changing the input information for each separate run. The 
GO method can find the time when a system changes from one state to another 
but it can not analyze a system which has more than one state change. 

In the GO- FLOW methodology signals correspond to the existence of physical 
quantities at various points in time. Sub -input signals to certain operators 
represent time information rather than probabilities and therefore can take 
on values greater than one. Signals are time dependent reflecting the fact 
that the GO-FLOW code is set up to perform time dependent unavailability 
analysis. 

Figure 2.8 shows the GO-FLOW chart for the light bulb problem analyzed 
in section five of Chapter 4. This figure is taken from reference M-2. The 
actual system diagram is shown in Figure 4.10 of Chapter 4. Each operator 
in the GO-FLOW chart of Figure 2.8 contains an operator type number 
corresponding to one of the 10 basic operators. This is the top number in 
each symbol. The lower number is simply the component number assigned. Each 
operator in the system must have a separate component number. Component 
number 4 is shown twice in the figure because it supplies a signal to two 
separate components. All signals in the system are also number sequentially 
indicating the time sequence which will be used in system analysis. Table 
2.2 summarizes the operators used in Figure 2.8. Table 2.3 defines the 
signals of the example system. Both of these tables are from reference M-2. 

Using the equations associated with each operator, as shown in Table 
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Figure 2.8 GO-FLOW Chart Example 
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2.1, it is possible to step through the analysis and determine the 
probability that at least one light is lit at each of the designated time 
points. Specifically, time points 1, 2 and 3 correspond to time t-0.0. Time 
point 1 is prior to any system change, time point 2 corresponds to connecting 
the battery, and time point 3 is when switch Si is closed. Time point 4 
corresponds to time t=10.0 hours, but prior to closing of switch S2, and time 
point 5 corresponds to switch S2 being closed (at t-10.0 hours). Time point 
6 is at t-20.0 hours. The output signal of each operator is determined at 
each time point by applying the operator equations. Signals are evaluated 
sequentially as numbered since input signals to operators must be determined 
before outputs can be calculated. Time points are also evaluated 
sequentially after all signals for the preceding time point are calculated, 
because certain operator types require knowledge of the previous input and 
output signals. These calculations are all done internally by the GO-FLOW 
program, but can be done manually if desired. 

For the example problem shown if Figure 2.8, which is also treated in 
Chapter 4, manual calculations were performed to calculate output signal 
intensities at each of the designated time points. The results indicate the 
probability that the indicated signal exists at the selected time point. 
These results are compared with simulation estimates in Chapter 4. Table 2.4 
provides a summary of the signal strengths calculated at each of the time 
points. The results shown for signal 12, the output of operator 12, are used 
in Chapter 4 for comparison with the results obtained using the simulation 
program method. 
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TeUsle 2.2 

Operators Used in GO-FLOW Sample Problem 



Operator 



Tvpe 


Number 


Data 




Me an in E 


25 


1 


R(1)=0.0, 

R(t)-1.0 (t not eqxial 


1) 


Battery is connected 


25 


2 


R(3)=1.0, 

R(t)-0.0 (t not equal 


3) 


Demand signal for switch SI to 
close 


25 


3 


R(5)=1.0, 

R(t)=0.0 (t not equal 


5) 


Demand signal for switch S2 to 
close 


25 


4 


R(4)-10.0,R(6)=10.0, 
R(t)“0.0 (t not equal 4,6) 


Time duration 


21 


5 


P, - 0.9 




Battery works with 
probability 0.9 


26 


6 


Pg - 0.7 




Switch SI closes normally with 
probability 0.7 


21 


7 


Pg - 0.8 




Light bulb LI works with 
probability 0.8 


35 


8 


X = 0.001/h 




Failure of LI while on 


26 


9 


Pg - 0.7 




Switch S2 closes normally with 
probability 0.7 


21 


10 


Pg - 0.8 




Light bulb L2 works with 
probability 0.8 


35 

22 


11 

12 


X - 0.001/h 




Failure of L2 while on 
OR gate 



Teddle 2.3 

Signals Defined in Sample GO-FLOW Problem 



Signal Definition 

1 Battery is connected 

2 Demand signal for SI to close 

3 Demand signal for S2 to close 

4 Time duration 

5 Battery provides power for both lights 

6 Power is available at LI 

7 LI lights up without demand failure 

8 LI is on 

9 Power is available at L2 

10 L2 lights up without demand failure 

11 L2 is on 

12 Either LI or L2 is on (final signal) 
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Table 2.4 

Calculation Steps for Seunple Problem 

Operator Signal Intensity of Output Signal for Time Points 1 to 6 



Number 


Input 


Output 


1 


2 


3 


4 


5 


6 


1 


--- 


1 


0.0 


1.0 


1.0 


1.0 


1.0 


1.0 


2 


— 


2 


0.0 


0.0 


1.0 


0.0 


0.0 


0.0 


3 


— 


3 


0.0 


0.0 


0.0 


0.0 


1.0 


0.0 


4 


... 


4 


0.0 


0.0 


0.0 


10.0 


0.0 


0.0 


5 


1 


5 


0.0 


0.9 


0.9 


0.9 


0.9 


0.9 


6 


5,(2) 


6,(5) 


0.0 


0.0 


0.63 


0.63 


0.63 


0.63 


7 


6 


7,(5) 


0.0 


0.0 


0.504 


0.504 


0.504 


0.504 


8 


7,(4) 


8,(5) 


0.0 


0.0 


0.504 


0.4990 


0.4990 


0.4940 


9 


5,(3) 


9,(5) 


0.0 


0.0 


0.0 


0.0 


0.63 


0.63 


10 


9 


10.(5) 


0.0 


0.0 


0.0 


0.0 


0.504 


0.504 


11 


10,(4) 


11,(5) 


0.0 


0.0 


0.0 


0.0 


0.504 


0.4990 


12 


8,11 


12 


0.0 


0.0 


0.504 


0.4990 


0.7236 


0.7191 



2.3 Karlcovian Analysis 



Markov models are useful in determining steady state and time dependent 
availability measures. Markov analysis techniques are predominantly applied 



to systems which are normally solved in continuous time. The major drawbacks 



of the method are that it can not easily be used to treat phased mission 



problems and the basic Markov models require all state transition rates to 



be exponentially distributed. 



To solve a complex phased mission problem using the Markov method would 
require using Markov chains in which the probability of being in any state 
is calculated up to the point where the possible states of the system are 
changed using straightforward Markov analysis. Then the new states are added 
to the analysis and new Markov equations are written. The results from the 
first stage are used to define the initial probabilities of being in any of 
the new states. The analysis progresses in time until the next point where 



the state space of the system is changed by an external event such as 
maintenance, testing, or a control function. The chain method can be used 
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to analyze process control system problems by discretization techniques, 
however for complex problems the Markov chains may become unmanageably large. 

Many fundamental system reliability and risk analysis texts such as 
references B-2, D-1, M-1, and P-1 give adequate descriptions of the basic 
Markov modeling techniques. The essential step is first to identify all of 
the possible states the system can be in. For a system of twenty components 
which can be in either an operating or a failed state there are possible 
system states indicating the need for reduction techniques to simplify the 
problem. These methods often involve the use of absorbing states and simple 
numerical procedures allowing for truncation and approximation of values. 
Reference P-3 by Papazoglou and Gyftopoulos discusses the technique of 
merging which can also be used to reduce the order of a Markov system. This, 
of course, can lead to results which are not exact, but can be made to have 
arbitrarily small error percentages. 

Once all system states are identified, a set of first order 
differential equations is written describing the rate of transfer in and out 
of each state. If the transfer rates are exponential and are constant with 
time, then the system is described by a set of linear, constant coefficient, 
first order differential equations and can easily be solved by any one of a 
number of methods. These include matrix exponentiation, Laplace transforms, 
eigenvalues, and discrete time integration techniques such as the Runge-Kutta 
method. For cases where state transition times are not exponential, the 
system of differential equations are no longer Markovian. These non- 
Markovian systems, which can be represented by discrete state spaces, may be 
solvable by one of the three techniques described in ref. P-1. These include 
the method of supplementary variables, the dummy states method, and the 
embedded chain approach. All of these techniques involve attempts to reduce 
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the system to an equivalent Markovian problem. However, large systems which 
can be explicitly modeled by these techniques are very rare and thus without 
the use of simplifying assumptions or approximate mathematical procedures, 
the use of these methods is extremely limited. 

Current work in the area of Markovian analysis centers around two 
areas. These include methods to reduce the order of the system and methods 
to incorporate dynamic system characteristics for modeling systems with 
phased mission scenarios. Several papers on recent work are considered here. 

In reference J-1, Johnson discusses a general availability model and 
basic modeling techniques. Rules for writing the state transition matrix 
and its eigenvalues and eigenvectors are given. Then formulas are discussed 
for computing approximate results for state probabilities based on the 
eigenvalues and eigenvectors. Three fundamental cases are examined to 
demonstrate the approach for determining steady state availability values. 
These three cases are a system involving no repair, a system of N components 
having identical repair and failure rates, and an N component system in which 
only one component can be failed at a time. The paper covers basic concepts 
and gives a general review of Markov modeling, 

Jeong, Chang, and Kim propose applying Markovian analysis techniques 
to fault tree evaluation in reference J-2, The purpose is to produce time 
dependent availability results of a continuous nature directly from the fault 
tree structures and to correctly incorporate component maintenance and 
testing, i.e. to model dependencies on the state of the system. Their method 
is to describe basic events in a modified fault tree by Markovian analysis 
techniques. The new tree contains numerous Markov states and includes system 
state dependencies such as whether or not components are undergoing 
maintenance. This new discrete state, continuous time model is quite large. 
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thus Jeong, Chang, and Kim introduce the concept of a super component to 
reduce the order of the transition matrix. These super components contain 
a number of basic events from the fault tree and provide the fundamental 
means by which the tree is converted to a Markovian process with a minimal 
number of states to be solved for. Results provide dynamic availability data 
for the system while incorporating maintenance and testing. 

Reference G-2 by Gray deals with simplifying complex systems. The 
method applies only to systems containing parallel active and redundant 
subgroups of identical components and should prove useful in designing and 
analyzing redundant systems. Each subgroup is analyzed using Markov 
techniques to determine the time dependent behavior of all components in the 
subgroup within the context of the subgroup as a separate unit. The 
reliability of the subgroup can then be determined. From the expression 
governing this relationship it is possible to calculate a mean and a standard 
deviation of the subgroup time to failure. If the time to failure can be 
modeled as exponentially distributed then the subgroup can be replaced by an 
"equivalent element." Then further decomposition may continue if a parallel 
subgroup of "equivalent elements" can be modeled in the same fashion. 

This method can greatly reduce the order of a complex system to be 
solved by Markovian analysis and therefore reduce the computer time necessary 
relative to matrix powering techniques used to solve the same problem. 
However, application is limited, as the method requires that there be 
parallel subgroups of like components, and even when such structures exist, 
they can only be replaced with "equivalent elements" if analysis of the 
subgroup shows it to have exponential repair and failure distributions, which 
certainly may not always be the case. 

An important characteristic of the Markov model is that at any time the 
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system can be completely described by specifying the state the system is in 
and all of the exponential transfer rates in and out of each system state. 
Solving the system of equations provides time dependent information about the 
probability that the system is in any one of the possible states, however if 
it is necessary to know the probability of transition between any two states 
at a specified time it is essential to use the Chapman-Kolmogorov equations. 
The Chapman-Kolmogorov equations are given by: 



where t ' < u < t 

These allow direct calculation of transition probabilities provided all 
possible intermediate transitions are determined first. In reference L-1 
Limnios describes a new method for numerical solution of the Kolmogorov 
equations for continuous time Markov chains. The method provides a very 
simple numerical treatment which can be applied directly in discrete time 
solutions of Markov systems. The error can be made arbitrarily small through 
proper choice of parameters. The procedure requires less operations than 
direct development for cases where the norm of the state transition matrix 
is large (greater than five). The larger the norm of the transition matrix, 
the greater the computational savings. This method will prove useful in 
numerical computer codes which solve Markov systems through the use of matrix 
exponentiation techniques. 

Another variation of the Markov approach is discussed by Aldemir in 
references A-1 and A-2. This method describes a dynamic failure model for 
evaluation of process control systems. The approach is unique in that most 
techniques consider simple binary components which are either failed or 
operational and this method considers continuous state dynamic variables 
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including such parameters as temperature, pressure, and liquid level. The 
method, which is described in detail in reference A-1, is based on discrete 
state space, discrete time representation of process control system dynamics 
and probabilistic system behavior simulated by Markov chains. An algorithm 
is developed for construction of the state transition matrix and input 
preparation for the algorithm is illustrated by example. The method is 
demonstrated to be effective for accurate failure analysis of process control 
systems . 

Markovian analysis procedures provide a means for determining system 
state continuous time (or discrete time) availability information. The 
method applies only to components with exponentially distributed repair and 
failure rates. Once the state transition equations are derived it is always 
possible to solve the system exactly although in many cases exact solution 
may require a prohibitive amount of computational effort. The mathematics 
involved can become extremely cumbersome as the size of the system increases 
since the number of system states expands exponentially with the number of 
system components. The method also does not lend itself well to phased 
mission analysis although Markov chains can be used as discussed above. 
Example Markov solutions are shown in conjunction with the sample simulation 
problems considered in Chapters 4 and 5. 

2.3.5 Monte Carlo Simulation 

Monte Carlo simulation is a system reliability analysis approach which 
has great potential for solving complex analysis problems. Descriptions of 
the method of Monte Carlo simulation for system reliability analysis can be 
found in references B-2 and P-1 and many other systems reliability analysis 
texts. The basic approach involves generating a computer model which 
simulates operation of the system under consideration. Random number 
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generators are used to model the random events in the system such as failure 
and repair of components. For each set of random numbers (experiment), the 
program is run and the result is a discrete time description of all system 
process variables and/or system component states. The experiment is 
performed a series of times and the results are averaged over all of the 
trials to provide an estimate of the system reliability. For example, if the 
availability of a system, A(t), is to be determined, the simulation can be 
run for N trials, each simulating system operation over a fixed time period, 
T. The value of A(t) for each trial can be stored for selected discrete time 
points to provide A(t | trial i) . An estimate of A(t) can then be made at 
the discrete time points using the equation: 



where A'(t) is an estimate of A(t) 

As N goes to infinity this estimate will approach the exact analytical 
result. The variance of the estimate A' (t) is proportional to 1/N, thus to 
reduce the standard deviation of the estimate it is necessary to increase the 
number of trials performed. 

There are advantages and disadvantages to the use of Monte Carlo 
simulation. One major advantage is that since a simulation model is 
developed to fit the problem, it is possible to quantitatively evaluate any 
system regardless of the form of the transfer rate expressions and the 
complexity of the system itself. In theory, results can be made as accurate 
as desireable by improving the modeling assumptions and running the 
experiment for an arbitrarily large number of trials. However, herein also 
lies the major disadvantage. To develop extremely accurate models for 
complex systems may involve a relatively large amount of time for formation 
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of the program and excessive cost in computer time for execution since the 
number of trials required to obtain acceptable results may be unreasonable. 
And, in general, references G-3 and P-1 agree that the amount of simulation 
time required to provide reasonable confidence in the results obtained will 
be far larger than the time required to acquire an analytical solution to the 
same problem, provided an analytic solution can be achieved. Monte Carlo 
simulation methods are being used in many engineering fields and one example 
is in the area of electric power generating system reliability. References 
A-3 and G-3 both deal with this subject in detail. In reference G-3, Ghajar 
and Billinton use Monte Carlo simulation to produce a generating system 
outage history over a period of time combined with a load model to determine 
adequacy indices. In this model start-up and shut-down of individual 
generating units are modeled and start-up failures are modeled distinctly 
from running failures. The model is applied to the IEEE Reliability Test 
System (RTS) and it demonstrates good agreement with analytical results. 

Reference A-3 by Allan, Jebril, Saboury, and Roman, similarly evaluates 
power system reliability using Monte Carlo simulation, but with a slightly 
different model. Results of this model for the IEEE RTS are compared with 
the analytical results and again the mean values of the Indices indicate 
favorable outcomes. It is noted, however, that the standard deviation or 
dispersion of the results is extreme even though mean values are consistent. 
This can be of major importance since relevant decisions may be made based 
on dispersion characteristics of certain indices. For this model it may be 
necessary to run a much larger number of trials or possibly to employ 
variance reduction techniques . 

Reference L-2 by Lewis and Zhuguo describes how Monte Carlo sampling 
procedures are used to solve inhomogeneous Markov processes. Inhomogeneous 
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Markov processes refer to systems which can be modeled by a discrete state 
space, but the transition rates are time dependent. These problems are 
solved with Markovian analysis techniques by using Monte Carlo sampling to 
determine the times between state transitions. It is explained that Monte 
Carlo methods are capable of treating Markov models which would be 
intractable by deterministic computational methods. In the reference, a 
model is developed which can treat Markov systems with time dependent 
transition rates and which allows for periodic testing and maintenance. The 
paper concludes with remarks concerning the development of future Monte Carlo 
simulation models for system reliability analysis which incorporate the 
concept of cumulative damage. 

Kumamoto, Tanaka, and Inoue describe a new Monte Carlo method for 
evaluating system failure probabilities in reference K-2. They explain that 
for extremely reliable systems the method of direct Monte Carlo simulation 
is not applicable since the number of trials required to obtain meaningful 
results would be prohibitive. This fact is well known and variance reduction 
techniques are applied to yield smaller variances with the same number of 
trials as direct Monte Carlo methods. Karp and Luby have previously 
developed the Karp-Luby minimum variance estimator (KLM) which is used to 
estimate the minimum number of trials necessary to achieve results which are 
accurate within certain variance limits. The KLM method can only be applied 
to a system if all the minimal cut sets are known. A variance is specified 
and then the KLM estimates the number of trials necessary to achieve 
satisfactory results with the Karp-Luby Monte Carlo method. 

Kumamoto, Tanaka, and Inoue have developed what they call the "New 
Coverage Monte Carlo" (NCM) method and an associated minimum variance 
estimator. Their method is very similar in nature to the Karp-Luby method. 
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however they are able to achieve results of equal accuracy with a far fewer 
number of trials thus saving considerable computer time. Their method can 
only be applied to systems composed of components with very small failure 
probabilities and the smaller the component failure probabilities are the 
more pronounced the benefit this method provides over the Karp-Luby method. 

Monte Carlo simulation methods are seen to be extremely useful in 
evaluating system reliability for complex systems which often can not be 
solved analytically. This method also allows for straightforward analysis 
of phased mission problems. It can be, however, quite time consuming to use 
and the results can have large variances associated with them. 

2.6 Chapter Siunmary 

The many methods for system reliability analysis can be broadly grouped 
into two basic categories. Those methods which provide static system 
Information and those which can be used to do d3mamic analyses. Of the 
static methods, fault tree analysis procedures and the GO methodology were 
considered. For dynamic analysis methods, event trees, digraphs, Markovian 
analysis, the GO-FLOW methodology, and simulation were discussed. 

The two static methods provide excellent tools for evaluating average 
system unavailability but have only limited applicability to solving dynamic 
problems . Separate program runs or computation sets must be done to evaluate 
the system at each discrete time point of interest. Also because of their 
static nature, they can not be used to solve phased mission problems without 
performing numerous intermediate analysis computations. 

Of the dynamic methods it was seen that availability information can 
be obtained for all manner of complex systems, however each method has its 
limitations or drawbacks. Event trees can not be used to treat systems which 
contain an indefinite number of failure and repair loops and are only quasi- 
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dynamic, as they involve the passage of time in the event tree sequencing of 
events. Markovian analysis provides detailed information about time 
dependent unavailability, but can only be applied to systems containing 
components with exponentially distributed transition times. GO-FLOW allows 
for consideration of any manner of transition time distributions, however it 
is only designed to treat discrete state devices. If continuously varying 
process variables are to be considered a complex discretization scheme must 
be developed. 

With the possible exception of the GO and GO-FLOW methodologies, all 
system reliability analysis techniques discussed require development of a 
model where all possible system states are clearly defined. An alternative 
to this type of problem analysis is the simulation approach. A Monte Carlo 
simulation approach can be developed which requires only an understanding of 
the components involved in the system and the relationships between them. 
In the next chapter a benchmark model is developed which provides a simple 
approach to determining the availability of complex systems . 
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Chapter 3 

DYMCAM Dynamic Simulation Model 
3.1 Introduction 

In Chapter 2, one of the methods discussed for evaluating the 
reliability of complex systems was the Monte Carlo simulation technique. 
There are many ways that this technique can be implemented using a computer, 
and the way the computer program functions, along with the usefulness of the 
simulation results, can be dependent on the simulation language which is 
used. In this chapter simulation languages are discussed in general and 
their benefits and weaknesses with regard to Monte Carlo simulation 
programming are examined. The SIMSCRIPT II. 5 simulation language is used 
for the dynamic simulation model developed in this work. It is described in 
the second section of this chapter along with an explanation of why this 
language is believed to be useful for a Monte Carlo simulation model of the 
type developed in this work. The SIMSCRIPT language is a powerful simulation 
tool and has not been used to its fullest extent in this work. The program 
developed here is a basic model designed to demonstrate fundamental features 
of a simulation approach to availability analysis, and limitations of this 
program should not be viewed as limitations of the SIMSCRIPT language or 
simulation in general. 

Following the discussion of simulation languages, the subsequent 
sections of this chapter describe in detail the design objectives that were 
used in developing the DYMCAM (DYnamic Monte Carlo Availability Model) 
program proposed. Certain assximptions were made to keep the initial DYMCAM 
program at a manageable size for this introductory work, and these 
assumptions are detailed explicitly in Section 3.3. The fourth section gives 
a detailed description of the DYMCAM program. This program has been written 
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in a very general form and throughout this work it is pointed out where 
simple modifications can be made to the program to make it more powerful or 
to meet specific needs. Many such modification proposals are included in the 
program description section of this chapter. For a detailed description of 
the input file format necessary to run the program, Appendix A should be 
consulted. The chapter concludes with a summary section. 

3.2 Simulation Languages 
3.2.1 2^ Overview 

To fully appreciate the method of Monte Carlo simulation for systems 
reliability analysis, it is necessary to understand simulation as a tool, and 
what its advantages and disadvantages are. Reference B-4 by Banks and Carson 
is an excellent text for studying simulation techniques. In addition, in 
reference B-5, also by Banks and Carson, there is a good description of 
several process -interaction simulation languages. Different simulation 
languages are designed to be used for certain types of problems and it is 
necessary to know which languages are best used for Monte Carlo problems. 
This section takes a general look at simulation approaches. 

It should be pointed out that in the area of system reliability 
analysis, simulation can be an important tool since there are numerous 
examples of large complex problems which cannot be solved by analytical 
techniques, Monte Carlo procedures are very useful for many such instances. 
Further, even in cases where analytical solutions are available it may be 
desireable to use simulation methods. The advantages and disadvantages must 
be understood, however. Presently, the methods of simulation are not widely 
used in reliability analysis. Reference S-1 by Schmidt and Taylor specifies 
some primary advantages and disadvantages of simulation and these are listed 



in Table 3.1. 
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Table 3.1 

Advantages and Disadvantages of Simulation 

Advantages : 

- Once a model is built, it can be used repeatedly to analyze 
proposed designs or policies. 

- Simulation models are usually easier to apply than analytic 
methods. Thus there are many more potential users of 
simulation models than of analytic methods. 

- Whereas analytic models usually require many simplifying 
assumptions to make them mathematically tractable, simulation 
models have no such restrictions. With analytic models, the 
analyst usually can complete only a limited number of system 
performance measures. With simulation models, the data 
generated can be used to estimate any conceivable performance 
measure . 

- In some instances, simulation is the only means of deriving a 
solution to a problem. 

Disadvantages : 

- Simulation models for digital computers may be costly, 
requiring large expenditures of time in their construction and 
validation. 

- Numerous runs of a simulation model are usually required and 
this can result in high computer costs. 

- Simulation is sometimes used when analytic techniques will 
suffice. This situation occurs as users become familiar with 
simulation methodology and forget about their mathematical 
training.^ 

There are several basic features which are desireable for a dynamic 
availability analysis model. These are: 

1. The model must contain general component models. 

2. Component history must be traceable to provide dynamic system 
information. 

3. Systems should be constructable by linking general component 
models . 

4. Interactions between components must be modelled. 

5. Scheduling of system changes at specified times must be possible. 



Taken from reference B-4 page 4, the original information comes from 
reference S-1. 
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6, For systems containing continuous process variables, a continuous 
simulation capability is necessary. 

Of these six basic characteristics, the first one is easily obtainable 
by any programming language. To create general component models it is 
necessary to define input and output parameters to the component, and a rule, 
or set of rules, which provide a means of determining the component output 
and state based on input infonnation. Figure 3.1 shows a general component 
model. It can be thought of as a box into which signals are fed and an 
output emerges. In addition to signals, information concerning failure and 
repair rates must be entered. To provide dynamic system information the 
signals must be able to change value as a function of time. All of these 
features are easily programmable in any computer language such as FORTRAN or 
PASCAL. 

The second necessary feature is the ability to track component history. 
Figure 3.2 shows a time line of performance for a specific component. The 
component is operational for a random length of time and then experiences a 
failure. There is a random repair delay modeled indicating passage of time 
before the failure is detected, and then once the failure is found, repair 
is begun. The component repair time is also random and once the component 
is repaired it is returned to its operational state. Note that, in general, 
the component need not be returned to its original state. To track the 
availability of systems composed of such components it is necessary to have 
features of the program language which allow for integration over time to 
detennine the average system unavailability, and which allow for sampling the 
system or component status at selected instants in time to determine the 
dynamic system unavailability at discrete time points. 

To allow the treatment of process variables (which are the fundamental 
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quantities determining system "success" or "failure"), it is necessary to be 
able to link all of the component models and allow them to interact with each 
other through the process variables. This requirement means that the output 
signal from one element will be used as the input signal to another 
component. This will cause the second component to react to whatever change 
may have occurred in the first component. In this manner, the failure (or 
change of state) of one system component can be propagated through the 
system. By linking the components in this fashion it is possible to create 
an entire system model out of the general component models. By requiring the 
components to change state based on their inputs the interaction between 
components will be modelled. Since in some systems it may be possible to 
produce loops of elements, it becomes necessary to continue propagating 
changes through the system in a cyclic fashion until no further changes 
occur. 

To simulate a dynamic system it is necessary to simulate the passage 
of time. This can be done by two different methods. The first is by 
discrete event simulation. In this method a queue is created into which 
events are entered along with their scheduled occurrence times. For example, 
a command signal causing a valve to close can be scheduled to occur at a 
specified time, or a pump could be scheduled to be placed in a standby 
condition to simulate the performance of maintenance. At a separate time, 
the valve may be given the command to open or the pump could be placed back 
in an operational state. Numerous such events can be scheduled and entered 
in the queue; events in the queue are ordered by their occurrence times. In 
discrete event simulation, the simulation clock is started and time is 
advanced to the time corresponding to the first event in the queue. This 
event is executed and the changes propagated through the system. Once the 
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system has reached a steady state indicating that all consequences of the 
initial change have been realized, the clock is advanced to the time of the 
next event in the queue. Operation continues in this manner until there are 
no more entries in the event queue. This type of event simulation assumes 
that no changes occur in the system between the scheduled discrete events. 
This will not be the case for systems involving continuous variables and 
another simulation approach is necessary for such systems. 

In continuous event simulation certain system parameters are 
continuously variable. This is true for process control problems, or any 
analyses which involve temperature, pressure, flow rates, or fluid levels as 
process variables. To simulate this type of system, time is advanced by a 
small time step and all system parameters are updated. If a component has 
changed state during the time step, this change is propagated through the 
system in the same manner as for discrete event simulation. After all 
changes have been made, the simulation clock is again advanced by the time 
step and all changes are calculated. Simulation is continued in this fashion 
until time has been advanced to the end of the desired simulation period. 

From the above discussion it is seen that there are three perspectives 
from which simulation languages can be constructed and these are discussed 
in reference B-5. These include process-interaction, event-scheduling, and 
continuous simulation. Process interaction provides modelling of system 
components as processes (groups of related events such as component failure 
and component repair) and then relates these processes to each other in a 
manner which allows the components to interact. Event scheduling allows for 
events to be scheduled in a queue for occurrence at a specified time during 
a simulation as is used for a purely discrete event simulation approach. 
Continuous simulation is used when variables of a continuous nature are to 
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be considered, in which case discrete event simulation is not appropriate. 
Any simulation language may use one or a combination of all of these 
approaches. The most powerful language to use from a systems reliability 
analysis standpoint would clearly be a language that employs all three 
positions, since a process interaction capability is desireable to easily 
model component interactions, event scheduling is desireable to cause the 
occurrence of such discrete events as system maintenance and testing, and 
continuous simulation is necessary to treat systems containing continuous 
variables . 

Any of the three approaches discussed above can be programed in general 
programming languages such as FORTRAN or Pascal. However, in recent years 
many program languages have been developed specifically for simulation 
applications . Some of these languages are based on languages like FORTRAN 
while others have been developed specifically for simulation problems. One 
example of discrete event simulation using a standard program language can 
be found in SIMTOOLS. This product, described in reference S-2, is a 
collection of data structures and routines which allow the writing of 
discrete event simulation programs in Pascal using the event view. This 
method may be simpler for individuals already familiar with the Pascal 
language, however it may not be as efficient as simulation with the languages 
which have been designed specifically to treat simulation problems. 

Many products are currently available for discrete event simulation. 
Several of these products are compared and discussed on reference B-4. Their 
approaches and modeling characteristics are summarized in Table 3.2 which 
gives a comparison of five languages including FORTRAN to illustrate which 
programs could be used to perform different simulation functions. It can be 
seen that as far as modeling approach is concerned, SIMSCRIPT II. 5 is 
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extremely versatile and could be used to model all types of random variables 
and event occurrences in a Monte Carlo simulation model, SLAM II is a 
simulation language which also allows for programming of all modeling 
approaches and could prove to be an equal alternative to the SIMSCRIPT II. 5 
language for coding of the program developed for this work. The other 
example languages shown do not have the adaptability to perform all the tasks 
modeled in the DYMCAM program and the modified DYMCAM program (TANK) 
described in Chapter 5 . 

It should be noted that although Table 3.2 includes FORTRAN for 
comparative purposes, it is certainly possible for anyone so inclined to 
create there own simulation language equal to, or better than, those 
mentioned here based on FORTRAN or Pascal. It is possible to write a FORTRAN 
program oriented to solving any type of system and using any one, or all 
three, of the modeling approaches, and although random sampling is not built 
in, there are several scientific subroutines available for random number 
generation in FORTRAN. In the following section the basic features of the 
SIMSCRIPT II. 5 simulation language will be discussed to describe the features 
available for the DYMCAM dynamic simulation model. 
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Table 3.2 

Comparison of Languages for Discrete-Event Simulation^ 

Language 

Criteria FORTRAN GASP IV SIMSCRIPT GPSS/H SLAM II 

LLJ 

Good Good Good 

Poor Fair Good 



Ease of learning 

Ease of conceptualiz- 
ing a problem 

Systems oriented 

toward 

Modeling approach 

Event - schedul ing 

Process- interaction 

Continuous 

Support 

Random sampling 
built in 

Statistics gathering 
capability 

List -processing 
capability 

Ease of getting 
standard report 

Ease of designing 
special report 

Debugging aids 

Computer runtime 

Documentation for 

learning language 
and for reference 

Self- documenting code 

Cost 



None All All 

No^ 

No^ 

No^ 

No 

Poor 

Poor 

Poor 

Fair 

Fair 

Excellent Good 
Very Good Very 

Poor Good Good 

Low Low High 



Excellent Excellent 
Excellent Excellent 

Queueing All 

No Yes 

Yes Yes 

No Yes 

Yes 

Excellent 
Good 

Excellent Excellent 

Good 

Good 
Good Good 

Very Good Very Good 

Excellent Good 
High Medium 



Yes 


Yes 


No 


Yes 


Yes 


Yes 


Yes 


Yes 



Excellent Excellent Good 

Good Excellent Good 

Excellent Fair 

Good Excellent Good 

Good Excellent Good 

Good 
Good Fair 



This table is Table 3.8 taken from Reference B-4. 
Modelling structures not built-in, but can be developed. 
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3.2.2 SIMSCRIPT II. 5 

There are many references available for explaining the SIMSCRIPT II. 5 
language and programming techniques for developing simulation models. The 
text by Law and Larmey (ref. L-4) is a beginning handbook for understanding 
the language. For a more detailed description on progr amm ing procedures, 
reference R-1 by Russell should be consulted. This latter book explains more 
of the complicated modeling methods than the introductory text. Other 
references used in development of the DYMCAM model include, reference C-1, 
reference C-2, and reference F-1. All three of these texts provide useful 
information for understanding the use of SIMSCRIPT commands and modeling 
techniques . 

SIMSCRIPT II. 5 is a general programming language which facilitates the 
development of a discrete -event simulation model. It allows for both process 
interaction and event -scheduling points of view, or a combination of the two, 
in simulation modeling. A language extension in current versions allows for 
continuous simulations. In addition, it also has powerful scientific 
computing and list processing capabilities which when used to there fullest 
degree can be more efficient, for a programmer, than FORTRAN. A unique 
feature of the SIMSCRIPT program is that it can be written in English-like 
statements. As a simulation language in comparison to FORTRAN, SIMSCRIPT 
performs many complicated automatic maintenance tasks and report generation 
functions. It is very well suited for all types of Monte Carlo simulation 
problems . 

Before proceeding, several SIMSCRIPT terms need defining to provide a 
basic understanding of simulation programming using SIMSCRIPT. For more 
complete descriptions the references noted previously should consulted. The 
basic terms to be described here include: SCHEDULING, ENTITY, PROCESS, 
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ATTRIBUTE, and SETS. 

SCHEDULING refers to the discrete event feature of SIMSCRIPT. An event 
queue is created and events are placed in the queue (scheduled) along with 
their time of occurrence. The events in the queue are arranged in the order 
of their occurrence time and executed in that order. Time then is advanced 
to the occurrence time of the next event in the queue. The queue is dynamic; 
as simulated time progresses, new events may be scheduled and other 
(previously scheduled) events removed from the queue . For example , a 
component failure can be scheduled to occur at a certain time. Once the 
failure has occurred, an event representing repair completion can then be 
scheduled. As an example of removing events from the queue, an event can be 
scheduled at the beginning of a simulation which restores all components to 
as-good-as-new condition at a specified time. This event can remove all 
scheduled component failures from the queue. Later in the simulation, the 
failures can be rescheduled to occur at later times . 

An ENTITY is a program variable and has a memory location allocated to 
it once it is created. Entities are of two t}rpes, permanent and temporary. 
Permanent entities are created once, at the beginning of the program, and 
exist throughout program execution. Temporary entities are created only when 
needed and memory can be made available again for other variables by 
destroying the temporary entity once it is no longer needed. This provides 
a means of keeping data structures contained in computer memory to a minimum, 
thus providing for more efficient program operation. Several identical 
entities can be created by using a pointer or indexing variable. For 
example, if a simulation is to contain 10 valves, the following lines of code 



could be used to create them: 
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reserve pointer(*) as 10 
for i equals 1 to 10 
do 

create a valve called pointer(i) 

loop 

Then to refer to a specific valve the pointer can be used. 

A PROCESS is a special SIMSCRIPT entity which has memory associated 

with it in the same manner as a temporary entity. It can have several 

identical instances created. For example, if a component is modeled as a 
process, several identical processes can be created, one associated with each 
component. The most important feature of a process is that it has a 
subroutine associated with it which can schedule events and interrupt other 
processes. A process subroutine can also contain statements which cause the 
execution of the routine to be suspended, and an event notice to be placed 
in the event queue to cause the process routine to continue execution at a 
later scheduled time. If a component is modeled as a process, then the 

failure of the component can be scheduled by the process and process 

execution suspended until this time has been reached. Once the failure time 
has been reached, the component process again begins execution in the line 
of code following the failure scheduling. Here a repair delay can be defined 
and execution suspended until the scheduled delay time has passed. Then 
repair can be scheduled in the same manner. A process can also create other 
processes or temporary entities. 

All entities and processes can have ATTRIBUTES associated with them. 
This is a way of creating a data array. For instance, a pump can be defined 
as an entity. Several pumps may be created. Associated with each pump there 
may be a demand failure probability, a failure rate, a repair rate, etc. 
These characteristics can be defined as attributes of the pump entity and 
thus when a pump is created, memory storage is also allocated for the array 
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of characteristics associated with it. Processes can also have attributes 
in the same manner. 

SETS are an important SIMSCRIPT feature. Several items which are of 
the same type can be grouped as members of a set. These members may be 
entities or processes, but must be one or the other, in a given set. For 
example consider a system containing 100 different input and output signals 
from ten system components. Several of the signals may be input signals to 
a given component. A signal set can be defined to group these signals. The 
set will be "owned" by the component process, and the input signals will 
"belong" to the set. Thus in SIMSCRIPT terminology, all sets must have an 
owner and may have any number of members which belong to the set. 

SIMSCRIPT also has useful statistics features available for evaluating 
system simulation. The two basic commands are TALLY and ACCUMULATE. The 
Tally command is used to compute statistics of a distribution, such as the 
mean and variance, at specified instants of time. The distribution can be 
an array variable. The Accumulate command tracks the behavior of en entity 
over the duration of a simulation. It performs integration with respect to 
time and can be used to determine the time -averaged behavior of a system 
entity. By properly defining the possible component states, this feature can 
be used directly to calculate time averaged system unavailability 
information. 

The process- interaction approach to simulation modeling allows 
SIMSCRIPT to be very useful in the analysis of complicated phased mission 
problems . Components can be modeled as processes thus allowing each 
component to control its own time dependent behavior. Failure and repair 
procedures can be included in the component process subroutine to provide 
scheduling of failure and repair times. By modeling testing and maintenance 
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as separate processes it is possible to correctly model random testing and 
maintenance events interrupting component operation and then restarting the 
components once they are completed. If it is desireable to limit repair 
resources, such as by limiting the number of components under repair at any 
given time, or if random repair delays are to be incorporated based on the 
number of components presently failed, it is possible to create a "repair 
supervisor process." This process could be used to schedule repair processes 
by interrupting and rescheduling selected component events. Event scheduling 
techniques do not readily allow this flexibility, since scheduling of certain 
events, such as repair completion times and testing termination intervals, 
are dependent on the occurrence of other random events and are therefore best 
modeled by processes rather than sequences of events. 

As an example, consider the time line of Figure 3.3A. A system is 
composed of two components with exponential failure distributions and 
constant repair time. Using discrete event scheduling, the failure and 
repair times can be scheduled for both components before the start of the 
simulation based on their failure rate and repair time data as shown in 
Figure 3.3A. The occurrence times are independent and do not interact with 
each other. However, if repair resources are to be limited such that only 
one component can be under repair at a time, then the event scheduling shown 
in figure 3.3A is not adequate. A repair supervisor process can be used 
which counts failures of components and schedules repair events. Then when 
the first component fails, the repair process will immediately schedule the 
repair time. When the second component fails, if the first component is 
still under repair, then the process can wait until repair of the first 
component is complete before repair is begun on the second component. This 
is illustrated in Figure 3.3B. This type of component interaction requires 
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Figure 3.3 Limited Repair Resource Modeling 
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some form of process interaction simulation approach to model adequately. 

The continuous capability is important for analysis of problems which 
have continuous random variables. It allows for straightforward analysis of 
process controls systems and like structures which include such continuous 
parameters as temperature, pressure, flow rates, or fluid levels. This 
program capability is taken advantage of in Chapter 5. The report generating 
functions are also extremely useful as they allow easy calculation of such 
system parameters as all statistical values and all time averaged quantities 
of interest. The SIMSCRIPT II. 5 simulation language provides many other 
valuable programing features useful for developing Monte Carlo simulation 
models and several of these shall be evident in later sections of this work. 
For more complete information the references should be consulted. 

3.3 Program Objectives 

The DYMCAM (Dynamic Monte Carlo Availability Model) base simulation 
program was developed with the three primary objectives. These objectives 
are: 1) provide a model which is able to analyze the time -dependent 
unavailability of dynamic systems, 2) provide a model which is easy to 
construct and interpret, and 3) provide a base model which can easily be 
expanded to incorporate additional features as needed. 

To analyze the time -dependent unavailability of a system it is 
necessary to consider two basic program abilities. The program must 
incorporate component repair and there must be a program feature which allows 
the scheduling of external events. Consider the time line of Figure 3.4. 
During the course of a simulation, two types of events must scheduled to 
cause changes in components of the system. These are internal events and 
external events . Internal events are failure and repair times of individual 
components. Scheduling of these events is controlled by the individual 
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Figure 3.4 Event Scheduling Approaches 
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component processes. External events are scheduled at the start of a 
simulation by the user. In the example shown these types of events could 
include such occurrences as changing the state of a valve from closed to 
open. The time -dependent availability of a system will depend on both types 
of events. 

Another time -dependent feature desired, is the incorporation of 
interactions between components based on process variables . When one 
component in a system changes state, it may have an impact on other 
components in the system. Thus the change must be propagated through the 
system to determine what effect there is on other components. For example, 
an open valve may be supplying water to an operating pump. If the valve 
fails closed, flow to the pump is stopped. If the pump does not stop on its 
own, it will fail. Even in the absence of directly caused failures such as 
this, it is necessary to propagate interactions to obtain the state of all 
process variables. 

To provide a model which is easy to use and interpret, it is necessary 
to provide component models in the program which correspond directly with 
physical components. This is a feature provided by both GO and GO-FLOW as 
was discussed in Chapter 2. It is also the approach adopted by Apostolakis, 
Salem, and Wu when constructing fault trees based on decision tables (ref. 
A-4) . The problem with GO was that it is designed to be used in static 
analysis cases. In the case of GO-FLOW, which is designed for time -dependent 
analysis, the method does not incorporate repair directly into its operators 
and can therefore not directly treat the failure and repair cycles of 
components. The equations of the GO-FLOW operators in Table 2.1 demonstrates 
this fact. 



The model to be developed should have a one-to-one correspondence 
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between physical components and model components and connections between 
components in the model should reflect actual component interactions in the 
physical system. Power and control signals to components must be modeled as 
well as process variables. The set of rules governing the possible changes 
in component state as a function of the various input signals supplied to 
them should clearly reflect the physical changes actually experienced. 

Since the model to be developed is to be a basic one, it should also 
be easy to modify so that additional feature may be incorporated. Such 
features may include non- exponential transitions, dependent repair and 
failure of components, uncertainty analysis, continuous process variables, 
and complex interactions. Specific features of the actual model will be 
discussed in section 3.5. 

3.4 Model Assumptions 

To implement the general model to treat the behavior of some simple, 
but realistic systems, a number of assumptions' are made as detailed in this 
section. Many of these assumptions can be relaxed at a future date if more 
work is to be done on the DYMCAM dynamic simulation model. They do not 
represent restrictions of the simulation language or the program, but merely 
modeling simplifications. Where applicable comments will be made concerning 
relaxing the assumptions. 

The base model considers exponentially distributed failure and Weibull 
distributed repair times. Dependent failure and repair are considered only 
to the extent that the loss of the process variable to an active component 
causes it to fail if it is in an operating state, and external events can be 
used to model shocks which fail several components simultaneously. 
Uncertainty analysis is not included. Continuous variables are included in 
the program modification described in Chapter 5. Complex interactions are 
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also considered, to a certain extent in Chapter 5, as operational states of 
components are dependent on the level of the continuous process variable. 

The output generated by the program is also of importance. The desired 
output of the DYMCAM program is a print out of the time dependent system 
unavailability and the average system unavailability over the duration of 
simulated time. The time -dependent unavailability can be printed in several 
fashions. If desireable, the user can specify an arbitrary set of time 
points between time zero (start of simulation) and the terminal time (end of 
simulation) and enter these time values directly in the input file. Or, if 
it is preferred, the number of time points desired can be specified in the 
input file and the program will automatically select the specified number of 
points, uniformly distributed over a linear or logarithmic scale between the 
starting time and the end time. 

For computing the average system unavailability over the duration of 
the simulation, the program uses the basic SIMSCRIPT 11,5 Accumulate 
commands. Over each simulated system run the total time the system was 
unavailable is determined and then divided by the total time. This value is 
stored for each run and statistics are taken to determine the average and 
standard deviation of the average unavailability over the number of system 
runs . The average and standard deviation are then printed in the output file 
along with selected percentiles of the distribution. If desireable, a simple 
program modification allows for printing of the average system unavailability 
for every trial. This is done in one of the example problems discussed in 
Chapter 4, 

To model system components, five component types were chosen. These 
include valves, check valves, switches, and generic active and passive 
components. Component types are defined by the number and type of input 
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signals, by the possible internal states of the component, and by the rules 
used to process the input/output signals as a function of the component 
state . 

A large number of engineering components can be modeled effectively 
using these basic elements. Active components, valves, and switches have a 
minimxim of three inputs which include a power signal, a command signal, and 
at least one process input. Passive components have a minimum of one input. 
They require at least one process input and do not require power or commands. 
All components can have any number of process outputs. Figures 3.5 to 3.9 
provide diagrams and rule tables describing the five component types. The 
rule tables are taken directly from the model program listing of Appendix B. 
Generally, at the start of a run, no component is initially in a failed 
state. Note that it is a simple matter to use an external event to change 
a component to a failed state at time zero. 

Changes can be forced on the system at any time through the use of 
external events . These external events can be scheduled to occur during the 
simulated system operating period and can be used to change the state of 
components or to change system signals, such as changing a command signal to 
tell a ptimp to turn on or off. The current model requires the times of such 
occurrences to be known before the start of the simulation and included in 
the input file. The programming language, however, will allow for the random 
scheduling of these external events. If this is desireable at a later date, 
it simply involves creating a process routine (similar to the repair 
supervisor routine) which schedules events in a random fashion. This type 
of routine may be useful for treating unscheduled testing and maintenance. 
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Figure 3.7 Valve 
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Figure 3.8 Check Valve 
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Figure 3.9 Switch 
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Component failure times are considered to be exponentially distributed. 
Component repair rates are assumed to be Weibull distributed. The SIMSCRIPT 
II. 5 language allows for many types of distributions, therefore it is an easy 
matter to change distribution types if others are more appropriate for 
certain applications. These changes can accommodate such time -dependent 
effects as component aging. 

Also concerning component transfer rates, the possibility of demand 
failures of active components, valves, and switches are considered. These 
data are entered in the input file® and applied to cases of the indicated 
component failing to transfer in either direction. For instance, a valve can 
fail to open when it receives a signal to open or it can fail to close once 
it receives a signal to close. This may be a problem if the two failure mode 
probabilities are of different magnitude, but this can be easily rectified 
by making minor changes to the program and the input file. 

Currently there is no capability to consider repair delays but as is 
discussed in an example of Chapter 4 these are easily including in the 
REPAIR. SUPERVISOR routine. If it is necessary to always consider repair 
delays for components, then it may be desireable to modify the component 
routine of the program to include a repair delay and to change the input file 
so that a repair delay time, or the parameters for a repair delay 
distribution can be entered. 

Concerning process signals in the program which will represent such 
system characteristics as fluid flow, pressure, temperature, or electric 
current, there is currently no provision in the model to determine signal 
magnitudes. It is assumed that the existence or non-existence of the signal 
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is enough to establish the state of components or of the system. In fact all 
components can have any number of process inputs and process outputs and 
where inputs are concerned, if the component has at least one input signal 
indicating it is on, then if the state of the component is correct, all 
output process signals will be "on". For the case of a two -out -of -three 
system (an example is considered in Chapter 4) it is possible to modify the 
program by changing the input requirements to a valve so that it does not 
produce output unless it has at least two input signals. This, however, is 
not a satisfactory solution, in general, if process signal strength is 
important in the system analysis. Again it would require modifications to 
all component routines and the input file to accommodate the notion of signal 
strength, but this could be accommodated by the SIMSCRIPT language and this 
is a minor point. Currently, there is no limit to the mamber of input or 
output process signals from any given component, so clearly, if signal 
strength is to be considered, an algorithm must also be included which 
divides the input signal strength between the available outputs based on the 
physics of the system. 

There are many basic assumptions in the DYMCAM dynamic simulation 
model, but most of them can be relaxed if time and effort is taken to modify 
the DYMCAM program. The SIMSCRIPT language provides numerous capabilities 
and can accommodate almost any feature that may be desireable in a Monte 
Carlo simulation model. It is readily apparent that Monte Carlo dynamic 
simulation modeling can be a powerful tool for reliability analysis. In the 
next section the DYMCAM program will be discussed in detail. 

3.5 Program Description 

In SIMSCRIPT II. 5 there are many language features which may not be 
familiar to those who are accustomed to other program languages. First of 
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all, every program is composed of many subroutines. Two subroutines which 
are common to all programs are the "PREAMBLE" and the "MAIN" subroutines. 

The PREAMBLE is essentially where all initialization is made for the 
execution of the program. The MAIN routine is where overall program 
execution is controlled from. For simple programs, this may be the only 
routine used other than the PREAMBLE. It is used to call the subroutines and 
to start and stop the simulation program. 

The DYMCAM program contains many subroutines, including the PREAMBLE 
and MAIN routines. Table 3.3 gives a list of all these routines and their 
basic purposes. A complete listing of the DYMCAM computer program is 
contained in Appendix B. The remainder of this section gives a brief 
description of the purpose for, and operation of, each DYMCAM program 
subroutine in the context of the program operational flow chart as shown in 
Figure 3.10. 

Several subroutines are executed before the beginning of actual system 
simulation. The first of these is the Input subroutine. The INPUT routine 
is used to read the data from the input file and record the information in 
the appropriate memory locations. In particular, it defines the 
characteristics of the components to be modeled. This routine is called once 
during the execution of the program from the MAIN routine. The next routine 
called from MAIN is RUN. INITIALIZE. This routine uses the input information 
just read in to link the system components together by filing signals in 
appropriate input and output sets of various components. It also records 
appropriate signals and components in files associated with each external 
event for reference when the external event is executed. This routine also 
initializes all entities. Variables which are not assigned values are 
automatically set equal to zero by SIMSCRIPT. 



Dynamic Simulation Model 



79 



The routine TRIAL. INITIALIZE is called from the MAIN program inside the 
loop which is executed once for each Monte Carlo trial which is to be run. 
Its purpose is to reset the state of all components and signals to the 
initial value they should have at the beginning of execution of the next 
simulation trial. 

Table 3.3 

DYMCAH Subroutines 



Subroutine 



Description 



PREAMBLE 

MAIN 

ACTIVE 

AVAILABILITY 

CALL. UPDATE 

CHECK. VALVE 
COMPONENT 

DEMAND. TEST 
EXTERNAL. EVENT 
FAILURE . TRANSLATION 
INPUT 
PASSIVE 

REPAIR. SUPERVISOR 

RUN. INITIALIZE 
RUN. OUTPUT 

SCHEDULE. AVAIL. SAMPLES 

SCHEDULE . EXTERNAL . EVENTS 

STOP. SCENARIO 

SWITCH 

SYSTEM. UPDATE 

TRIAL. INITIALIZE 
VALVE 



Defines all Entities and Processes 
Controls overall execution 
Controls Active components 
Process that takes time -dependent 
data for unavailability 
Process that causes delay then 
calls Update routine 
Controls Check Valves 
Process to control failure and 
repair of Components 
Determines failure on demand 
Process to execute External Events 
Function to determine failed state 
Reads input file 
Controls Passive components 
Process to allocate Repair 
resources 

Initializes Variables for Run 
Prints output results to a file 
Process to cause recording of time 
dependent unavailability data 
Process to schedule External Events 
Stops execution of all processes 
Controls Switches 
Propagates Component changes 
through the system 
Initializes Variables for a Trial 
Controls Valves 



The next two routines called from inside the loop of the MAIN routine 
are the scheduling modules. The SCHEDULE. AVAIL. SAMPLES process is used to 
schedule interrupts in the execution of a simulation run to sample the system 
unavailability. The sample times specified by the user are entered in the 
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Figure 3.10 DYMCAM Program Flow Chart 



Dynamic Simulation Model 



81 



event queue for subsequent simulation interruption for system sampling. The 
actual recording of the availability information is done by the AVAILABILITY 
process. There is an AVAILABILITY process for each time point specified by 
the input file and each one collects data for its assigned time point. 
These samples are totaled for each particular sampling time and divided by 
the total number of trials in the output routine to determine the system 
time -dependent unavailability. The SCHEDULE. AVAIL. SAMPLES routine is only 
to schedule the interruptions for sampling by placing event notices in the 
event queue . 

The SCHEDULE. EXTERNAL. EVENTS process is used to schedule the interrupts 
in the execution of the simulation run for the processing of external events. 
It schedules these interrupts to occur at the specified times indicated by 
the input file. For every external event there is an EXTERNAL . EVENT process. 
Each EXTERNAL. EVENT process has a component set and a signal set associated 
with it which specify which components and signals are to change. These 
changes are performed when the external event is executed and then control 
is passed to the SYSTEM. UPDATE routine. EXTERNAL. EVENT processes are created 
by the RUN. INITIALIZE routine along with their associated component and 
signal files. 

Also inside the loop in Main is the STOP. SCENARIO routine. It is used 
to stop the execution of all processes which have not concluded at the end 
of a trial and to reset the execution of each component to its original 
operating condition. 

The CALL. UPDATE process exists inside the loop of the main routine to 
escape a complication associated with the simulation language. Any series 
of commands executed sequentially without undergoing the simulated passage 
of time must not contain commands which start and stop the same process or 
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create and destroy the same entity. It is also not possible to activate the 
same process twice. The program is designed so that on the initial trial of 
a run, all component processes are activated at time zero by the 
RUN. INITIALIZE routine. Thus a notice is put in the scheduled events list 
which will be executed once the timing routine is begun. One of the first 
statements in the COMPONENT process is a command to suspend operation, since 
some components, e.g. standby components, may not be operating at the start 
of the simulation. Standby components are not allowed to undergo failure in 
this model and therefore should not have failure times placed in the event 
queue until they are placed in an operational mode. The components that 
should be operating are then restarted by the SYSTEM . UPDATE routine. 

The problem is that the SYSTEM. UPDATE routine should be executed from 
the loop of the MAIN routine before the passage of simulated time is begun. 
This would cause an error since the sequential execution of commands would 
make it appear that a COMPONENT process has been scheduled to start twice. 
Therefore the CALL. UPDATE routine is included in the MAIN program loop. Its 
sole purpose is to wait a short period of time so that the simulation clock 
is started and all components are in the suspended state before the 
SYSTEM . UPDATE routine is executed and the operation of selected components 
is started again. 

The SYSTEM. UPDATE routine will be called many time during the execution 
of a simulation program run and it performs many functions. The first time 
it is called, it is used only to activate the components which should be 
operational at the beginning of a simulation. These components will advance 
from their original suspended states and begin their failure and repair 
cycles. Thus at the beginning of the simulation each operating component, 
if it has a non-zero failure rate, it will have a failure time scheduled for 
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it in the event queue. 

At this point the simulation is started. Currently there are three 
types of events scheduled in the event queue. These are component failures, 
availability samples, and external events. The simulation clock will be 
advanced to the time corresponding to the first event in the queue, the 
notice scheduling the event will be removed from the overall schedule, and 
the event will be processed. 

If the event is an external event then an EXTERNAL . EVENT process will 
be executed. Components in the external event component set and signals in 
the external event signal set for this external event will be changed to 
their new values. Then the SYSTEM. UPDATE routine will be called. 

If the event is an AVAILABILITY sample, then the system indicator 
variable, which indicates whether or not the system is in a satisfactory 
state, will be tested. The result will be summed with previous and future 
results for that particular time point, and stored for use in generating the 
output file. No change to the system is made by this interruption, therefore 
time is advanced to the next event in the event queue without any changes to 
the system being performed. 

If the event is a component failure, then the COMPONENT process for 
that particular component will again begin operation. The function 
FAILURE. TRANSLATION will be called and used to determine the state of the 
failed component. The failed state will be dependent on the type of 
component and the initial state, e.g. an open valve will fail closed and a 
closed switch will fail open. FAILURE. TRAN SLAT I ON is an example of the use 
of the SIMSCRIPT function command which simplifies programming when a series 
of commands is reused often. The commands in the FAILURE. TRANSLATION 
function could be placed in the COMPONENT routine without complicating 
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execution of the program. Once the type of failure is determined, a 
REPAIR. SUPERVISOR process will be activated and the SYSTEM. UPDATE routine 
will be called. 

The SYSTEM. UPDATE routine is used to connect all system components. 
It is called any time a component changes state or an external event is 
activated. It looks for changed signals or components and if it finds a 
change, it calls the response function (SWITCH, VALVE, etc.) for that 
particular component or the component which contains the altered signal in 
its input signal file. If this component changes state, or its output signal 
changes strength, then it will be necessary to propagate this change through 
the system. The routine continues to call affected components until no 
further changes occur. This routine also monitors the overall system state 
and changes it as necessary to reflect whether the system is available or 
unavailable as a unit according to the definition provided in the input file. 

The SYSTEM. UPDATE routine handles the loops which must occur in a 
process interaction system. The routine stores the value of all system 
signals and then looks for changes to this set. If a signal changes value 
then this is an indication that changes are still occurring in the system. 
The routine looks for components which have changed state or whose input 
signals have changed strength and calls the associated response function to 
ensure the component is in the proper operational state. If it is not, it 
may change according to its response function and new output signal strengths 
may be generated. These outputs are inputs to other components, so these 
components must also be updated. Since the possibility exists for loops to 
occur in system component structure, once all components have been checked 
once, the new signals are compared with the old signal strengths. If a 
difference is indicated, then it is possible that a component is not in its 
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desired state, thus the affected components are evaluated again. This 
process continues until the value of all signal strengths at the end of an 
iteration, equal the value of the signal strengths at the beginning of the 
iteration, indicating that no component has changed state during the last 
iteration. Since infinite loops may be possible, a maximum number of 
iterations is specified, which, if exceeded, causes an error message to be 
printed. 

Another important function of the SYSTEM. UPDATE routine is to reset 
the "failure clock" for components which change state. For example, whenever 
an Active component is placed in standby from an operating condition, the 
COMPONENT process associated with the Active component is reset so that when 
it begins operation again it will start a new failure clock. This program 
feature is very important for the analysis of phased mission problems where 
it is feasible that a single component may be turned on and off several times 
during a simulation run. 

The five routines entitled ACTIVE, PASSIVE, CHECK VALVE, VALVE, and 
SWITCH are the response functions called by the SYSTEM. UPDATE routine used 
to determine the state of all system components and the value of their output 
signals. These routines are used to change the state of components when a 
new command is received or the strength of an input signal changes. Each 
routine tests the state of the component and the value of all input signals 
and compares the results to a set of control "rules" to determine the new 
component state and the value of all of the component output signals. If the 
component is Active, a Valve, or a Switch and it has been called upon to 
change state, then the DEMAND. TEST routine is called to determine if the 
component has failed or not. The DEMAND. TEST routine's sole function is 
determine if a demand failure occurs based on the demand failure probability 



Dynamic Simulation Model 



86 



for the component. Once the tests are performed and the component state is 
modified, execution is returned to the SYSTEM. UPDATE routine. 

After a component has undergone failure and the effect propagated 
through the system, the REPAIR. SUPERVISOR routine is called. The 
REPAIR. SUPERVISOR process is not developed at this point to meet all of its 
potential. This process is currently used to start a repair process once a 
component is failed. Thus it simply reactivates the component process which 
controls the repair time calculation for the component. The repair process 
is activated from the COMPONENT routine whenever a component fails. The 
listing of the REPAIR. SUPERVISOR process in Appendix B contains a version 
which immediately starts a repair once a failure has occurred. Line 31, 
which causes a Weibull distributed repair delay, is not being used (it is 
"commented" out). It is used in one of the examples of Chapter 4. By 
changing the values of a and b in lines 23 and 24 it is possible to change 
the repair delay distribution. However, if • different repair delay 
distributions are desired for different components, then the input file 
structure and other program characteristics must be changed. 

The REPAIR. SUPERVISOR process could also be used to limit the amount 
of repair resources available. It is a simple matter to count the number of 
components failed and the number of components under repair by checking the 
status variable associated with each component. Then if too many components 
are failed it is feasible to delay repair of some components until repair is 
finished on other components. It is possible to prioritize repair based on 
which component has been failed the longest since when a component fails its 
failure time is recorded. If other prioritization schemes are desired they 
can be programmed in to the REPAIR. SUPERVISOR process. 

The COMPONENT process is used to control the transfer between good and 
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failed states for all components of the system. There is a COMPONENT process 
for each system component and these Components are created by the 
Run. Initialize routine. Within the COMPONENT process there is a section 
which controls the transfer from operational to failed and a separate section 
which controls the transfer from failed to operational. Whenever a component 
changes state the SYSTEM. UPDATE routine is automatically called to propagate 
the component change through the system as discussed above. Under the 
current program structure, when a component changes state from operational 
to failed, the component goes to a suspended state. The repair process is 
not begun until the REPAIR. SUPERVISOR process reactivates the component. 

Once the STOP . SCENARIO event is reached in the event queue, the 
STOP. SCENARIO process is executed. This process removes all remaining events 
from the event queue and resets all component processes so that all system 
processes are ready to begin operation for the next trial. With no events 
now remaining in the event queue, operation of the program is returned to the 
MAIN routine which causes the RUN. OUTPUT routine to be called. The 
Run. Output routine is used to write the program results to an output file. 
The results provided are of two t 3 rpes . There is a print out of the time 
dependent unavailability data and there is a list of the average system 
unavailability distribution. Examples of output files are included in 
Appendix E and will be discussed in Chapters 4 and 5 . 

3 . 6 Chapter Summary 

In this chapter the DYMCAM dynamic simulation model has been discussed. 
The discussion began with a review of some currently available simulation 
languages. These various approaches of event scheduling, process 
interaction, and continuous simulation were discussed and it was pointed out 
that all approaches are valuable to Monte Carlo simulation for complex 
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systems. It is recognized that SIMSCRIPT II. 5 contains programming 
characteristics allowing for use of all three modeling approaches. Table 3.1 
shows a comparison of four simulation languages along with FORTRAN and it is 
clearly evident that SIMSCRIPT is at least as good as, if not better, than 
the other languages for Monte Carlo simulation applications to evaluate 
system reliability. A discussion of SIMSCRIPT II. 5 programing features is 
also included. 

Sections 3.3 of the chapter dealt with the program objectives for the 
DYMCAM model and section 3.4 discussed the basic assumptions made. In the 
final section of the chapter the DYMCAM program is described. Its many 
subroutines are listed and brief explanations given of what the purpose of 
each routine and process is, to give a general understanding of what the 
program does. For a complete discussion of input file preparation for the 
DYMCAM program. Appendix A should be consulted. A complete program listing 
is provided in Appendix B. Specific program features and limitations will 
also be covered in the discussions of particular problems tested in the 
examples of Chapter 4 and Chapter 5. The next chapter of this work deals 
with tests of the basic DYMCAM dynamic simulation model. 
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Chapter 4 

Test Runs and Results 

4.1 Introduction 

The DYMCAM program was developed as a basic benchmarking model to 
demonstrate the capabilities of a simulation approach to solving system 
availability analysis problems. It does not give results that are 
necessarily any better than other methods, but it has the advantage that it 
can solve more complex problems. The capabilities of the basic DYMCAM 
program are: 

1) It can model external events necessary for phased mission 
problems . 

2) It treats exponential failure and Weibull repair distributions. 

3) It provides dynamic unavailability information about the system 
and also average unavailability information. 

4) The base model can be easily modified to treat more complex 
analysis problems. 

In this chapter several basic tests of the DYMCAM program are conducted 
to demonstrate these capabilities. The results obtained are compared with 
analytical results were applicable, and with numerically generated results 
in the more complicated examples. A fourth order Runge-Kutta method, 
obtained from reference P-4, is used to solve the Markov equations for the 
systems which can be modeled by this approach. The GO-FLOW example is 
compared with exact results as computed using the GO-FLOW method. 

The first problem considered involves a single component with 
exponential repair and failure times. For this example, which can easily be 
modeled as a two state Markov system, the governing equations can be solved 
analytically for comparison. The second illustration also involves a single 
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component with exponential repair and failure; in addition, it includes a 
second repair state which also has an exponential transition time. This 
three state problem can be solved analytically using a Markovian approach. 

The third problem involves three pumps in parallel, in series with a 
valve. Success of the system requires two of the three pumps to operate and 
the valve to be open. This problem involves a slight change to the program 
to consider the requirement for flow to be present from two pumps. For this 
problem there are sixteen possible system states with four of the states 
leading to system success. To solve the sixteen Markov equations would be 
difficult to do analytically, therefore the numerical Runge-Kutta integration 
method is used. 

The final example pertains to a GO-FLOW model. This approach is used 
to solve phased mission problems, therefore a comparison would show the 
usefulness of the DYMCAM program for solving a phased mission problem. 
Results are compared with the analytic results obtained from the GO-FLOW 
solution to the problem. In addition, this problem is used for a sensitivity 
analysis of the program to demonstrate the variation of the accuracy of the 
DYMCAM program results with the number of Monte Carlo trials performed. 

The chapter concludes with a summary of the performance of the basic 
DYMCAM dynamic simulation model over the test cases considered. General 
comments are made concerning the demonstrated capabilities and the accuracy 
of results. Consideration is made of how this approach compares with other 
system reliability analysis methods. 

4.2 Single Component, Single Repair State 

The first example problem to be tested on the DYMCAM program is a very 
basic example for which an analytical result is readily available. The 
analytical equation governing the unavailability of the component is: 
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Q(t) = - expC-(A+/i)t]} (4.1) 

where A = failure rate 
/z = repair rate 

and 

Q(t) = probability component is failed at time t 
The illustration is a single component with exponential repair and failure 
rates. For ease of examination, equal repair and failure rates were 
considered. The asymptotic value of system unavailability is clearly 0.5 
since the component will spend equal time in each of the two possible states. 

The DYMCAM program computes both instantaneous unavailability of a 
system to provide the dynamic output, and it computes the average 
unavailability. Instantaneous availability is computed by stopping the 
simulation (during each Monte Carlo trial) at a user-specified time and 
checking the system to see if it is in a failed state. A success state is 
indicated if the system indicator variable is equal to one, and failure is 
indicated by a zero. Thus the system indicator value is summed over all of 
the Monte Carlo trials for each selected time point. A different variable 
is kept to sum the value for each time point. After all runs are completed, 
the totals of these variables are divided by the number of trials. If the 
result equals one, then the system was always available at that time point. 
If the result is zero, then the system was always unavailable. Numbers 
between zero and one reflect the probability that at the instant of the time 
point, the system was available. Thus by subtracting all values from one, 
an estimate of the instantaneous unavailability is made for each selected 
time point. The simulation result is an estimator for the exact result given 
by equation 4.1. The simulation estimates apply at the discrete points 
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Time 



First Monte Carlo Trial 
Second Monte Carlo Trial 



Figure 4.1 Simulation Unavailability Time Line 
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chosen for analysis in the program. 

Average unavailability is calculated over the duration of a simulation. 
Consider the time line of Figure 4.1. For each trial there will be a 
distribution similar to the ones shown, but with failure and repair events 
occurring at different times. For each Monte Carlo trial the area under the 
curve is integrated and divided by the total simulation duration time. This 
is an automatic function available in SIMSCRIPT. Since the height of the 
line in Figure 4.1 is one, the integral of the area under the curve simply 
equals the total time during the simulation duration for which the system was 
unavailable. By dividing this result by the total simulation time, an 
estimate of the average unavailability is obtained. For each trial this 
result will be slightly different, thus the average unavailability is stored 
for each trial, and after all trials are completed, a mean, a variance, and 
selected percentiles of the distribution can be printed. The resulting 
distribution is an estimator of the exact result given by the equation: 



To perform the test for proper asymptotic results, the failure and 
repair rates were chosen to be 0.01 per hour. Thus after approximately 2Q0 
hours the system will have reached its asymptotic condition. Each simulation 
run covers 10,000 hours. For the simple system only 100 Monte Carlo trials 
were run to give satisfactory results. To show the fluctuations in 
unavailability about the asymptotic value, the system instantaneous 
unavailability was printed at every 500 hours of the simulation. To see the 
average system unavailability the time averaged system unavailability for 



Q. 



'average 



(for 0 < t < T) 




each trial was printed. 

Table 4.1 shows the fluctuation of the instantaneous system 
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unavailability about the desired value of 0.5. Over the relatively small 
number of Monte Carlo trials performed we see that there is a rather large 
fluctuation. This can readily be reduced by increasing the number of trials 
since the standard deviation of the result is related to the number of trials 



by one over the square root of the number of trials. 

Table 4.1 

Single Component, Single Repair State, Instantaneous Unavailability 



TIME UNAVAILABILITY 



0.0 


0.0 


500.0 


0.52 


1000.0 


0.38 


1500.0 


0.51 


2000.0 


0.60 


2500.0 


0.48 


3000.0 


0.48 


3500.0 


0.46 


4000 . 0 


0.51 


4500.0 


0.47 


5000.0 


0.45 


5500.0 


0,56 


6000.0 


0.41 


6500.0 


0.54 


7000.0 


0.48 


7500.0 


0.45 


8000.0 


0.50 


8500.0 


0.51 


9000.0 


0.57 


9500.0 


0.55 


10000.0 


0.49 



Using the values of time averaged unavailability for each of the 100 
Monte Carlo trials, a graph was constructed showing the distribution of 
unavailability values. This is shown in Figure 4.2, This figure portrays 
basically the same infoirmation about the model as Table 4.1. The difference 
is that Table 4.1 provides data that was computed using the instantaneous 
unavailability estimation procedure discussed in conjunction with equation 
4,1 and Figure 4.2 shows the distribution of the time averaged unavailability 
estimator as discussed in conjunction with equation 4,2. The exact average 
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SINGLE COMPONENT 
SINGLE REPAIR STATE {X=/j,=0.01) 




Figure 4.2 Single Component, Single Repair State 
Average Unavailability 
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unavailability can be found by performing the integral in equation 4,2. 
Doing this integration, where X - y - 0,01, the result is found to be 0,4975 
following 10,000 hours of operation. This result agrees within less than 
one percent with the mean value of the distribution shown in Figure 4.2. The 
variance of the distribution indicates a standard deviation of the result of 
+ 0.05. For many applications this deviation may be insignificant. The 
standard deviation can be reduced by increasing the number of Monte Carlo 
trials performed as shall be demonstrated in a later example. 

Another area of interest is whether or not the DYMCAM program provides 
adequate time dependent unavailability information. Another test was run 
with the same example problem only over a simulated time period of 200 hours. 
To reduce the wide variance experienced in the above example the number of 
Monte Carlo trials was increased to 1000. For comparison the results are 
plotted in figure 4,3 with the analytic results obtained by Markov analysis 
of the two state component as shown in equation 4.1. 

Figure 4.3 shows that the simulation model provides good time dependent 
results for this example. At large values of time, however, it is seen that 
the simulation starts to deviate from the desired results. In fact, for 
times greater than 200 hours, the simulation continues to fluctuate above and 
below the desired 0.5 value for unavailability. This, again, is a 
demonstration of the fact that there will be statistical fluctuations in a 
Monte Carlo simulation. The fluctuations are smaller the larger the number 
of trials used. 

A final point of concern with a simulation approach to systems 
reliability analysis is the computer time required to perform the analysis. 
For this simple one component system the time required to obtain the above 
results was approximately 30 minutes on an IBM compatible XT machine running 
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CDF 

SINGLE COMPONENT 
SINGLE REPAIR STATE (A=At=0.01) 




Figure 4.3 Single Component, Single Repair State 
Time Dependent Unavailability 
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at 7.16 MHz. The average unavailability test required a large amount of time 
due to the long simulated time period of 10,000 hours, which allowed for an 
average of fifty failure and repair cycles per Monte Carlo trial. The value 
of fifty is assumed since if the mean failure and repair times are both equal 
to 100 hours, then every 200 hours the component will, on average, go through 
a complete cycle of failure and repair. The time dependent analysis required 
30 minutes to run even though it simulated a shorter time period, because the 
unavailability of the system was sampled once every simulated hour (200 
points) which slowed down program execution. The program runs in about one 
sixth the time on a COMPAQ 386 machine. Methods of reducing computer time 
required are discussed in Chapter 6. 

4.3 Single Component, Dual Repair State 

The second example problem is an extension of the first, which 
demonstrates a capability of the REPAIR. SUPERVISOR routine (a subroutine in 
the DYMCAM program that determines when component repair is initiated) and 
the ease at which the DYMCAM program can be modified to meet specific 
applications. The problem involves a single three state component which has 
an exponentially distributed repair delay time before the component begins 
the repair process. 

In Appendix B the entire program listing is shown. In the 
REPAIR. SUPERVISOR process routine, line 31 contains the WAIT command used to 
create the third component state. It has been modeled as a Weibull 
distributed variable, but by proper choice of the parameters, the Weibull 
distribution becomes an exponential distribution. The Weibull distribution 
is characterized by the equation: 




(4.3) 
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where, a and b are the distribution parameters. By letting the parameter a 
equal 1.0, the Weibull distribution becomes an exponential distribution with 
lambda equal to 1/b. Lines 23 and 24 define the exponential distribution 
with a mean failure rate of one failure every 100 hours. If, in the future, 
it is desireable to enter different delay distributions for various 
components, the parameters for the Weibull distribution can be read in the 
INPUT routine in the same manner as the repair distribution parameters. 

The failure and repair rates for this example were chosen the same as 
for example number one. Thus with a mean repair delay time of 100 hours, the 
component now has three equal transfer rates from its three states. Thus it 
is evident that for the asymptotic case, the component will spend equal time 
in each of the three states . The component is only available when it is in 
its operational state, thus the asymptotic unavailability is two thirds. 

To test the asymptotic unavailability the DYMCAM program was run for 
a simulated component operation of 10,000 hours and 100 Monte Carlo trials. 
As in example one, the component was modeled as a passive element, although 
results would be the same for modeling the component as any of the other four 
elements for this simple case. Again the unavailability was sampled at 500 
hour intervals to show the fluctuation of the value around the expected value 
of 0.6667 corresponding to two thirds. Table 4.2 shows the results which 
indicate again that for the small number of Monte Carlo trials used, the 
variance is quite large. 

For this test the average system unavailability was also printed out 
for each of the 100 Monte Carlo trials. The range of values was divided into 
nine bins and the number of trials in each bin plotted against the central 
unavailability value for that bin. The results are shown in Figure 4.4. By 
using the fourth order Runge-Kutta technique to determine the time dependent 
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component unavailability over the 10,000 hour period, as is done for Figure 
4.5, and then numerically integrating the result from time zero to 10,000 
hours and dividing by the total time (10,000 hours), the exact result is 
found to be 0.6634. This indicates that the first 200 hours of operation did 
contribute slightly to lowering the result obtained. The simulation result 
agrees with the exact result within less than one percent difference. Again 
the standard deviation of the simulation result is + 0.05 which may be 
insignificant for some analyses. 



Table 4.2 

single Component, Dual Repair State Instantaneous Unavailability 

TIME UNAVAILABILITY 



0.0 


0.0 


500.0 


0.63 


1000.0 


0.70 


1500.0 


0.70 


2000.0 


0.68 


2500.0 


0.67 


3000.0 


0.65 


3500.0 


0.67 


4000.0 


0.72 


4500.0 


0.69 


5000.0 


0.64 


5500.0 


0.59 


6000.0 


0.63 


6500.0 


0.68 


7000.0 


0.65 


7500.0 


0.68 


8000.0 


0.69 


8500.0 


0.68 


9000.0 


0.61 


9500.0 


0.70 


10000.0 


0.64 



To compute the time dependent unavailability of this component the 
simulation time was reduced to 200 hours, and the number of trials increased 
to 1000 to reduce the variance of the results. Unavailability samples were 
taken every simulated hour and the results are plotted in Figure 4.5. For 
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SINGLE COMPONENT 
DUAL REPAIR STATE (X=/x^=/j.^=0.0l) 




Figure 4.4 Single Component, Dual Repair State 
Average Unavailability 



UNAVAILABILITY 



Dynamic Simulation Model 



102 



CDF 

SINGLE COMPONENT 




Figure 4.5 Single Component, Dual Repair State 
Time Dependent Unavailability 
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this example it is also possible to derive the analytic equations for the 
probability that the system is in any one of its three states using simple 
Markov procedures . The three equations are : 



Rather than solve these equations using Laplace transforms or matrix 
exponentiation techniques, a fourth order Runge-Kutta numerical integration 
routine taken from reference P-4 was used. The time dependent probability 
of the component being in state 0 was calculated and the result was 
subtracted from one to give the component unavailability. This result is 
plotted in Figure 4.5 for comparison with the simulation results. 

From Figure 4.5 it is seen that the simulation program again gives good 
results for the time dependent unavailability. As the value of simulated 
time increases there is a fluctuation of the simulation results about the 
desired value, but as explained before this can be reduced by increasing the 
nximber of trials. The computer time required for these two experiments was 
comparable with the first example problem (approximately 30 minutes) . The 
addition of the third component state did not significantly alter the time 
required to complete the run. The most important contributions to running 
time appear to be the length of simulation time for each trial and the number 
of time samples taken during each trial (the sampling process interrupts the 
simulation) . 




(4.4) 




(4.5) 



dP2 

dt ■ ”^2^2 where A = /i^ = /«2 = 



(4.6) 



4.4 Two Out of Three Pumps 

The third test case considers a more complicated system composed of 



Dynamic Simulation Model 



104 



three pumps connected in parallel. Figure 4.6 shows a diagram of the system. 
The output of the pumps is fed to a common header where the flow then enters 
a valve. Success of the system requires at least two pumps to be operating 
and there to be flow output from the valve. The DYMCAM program, as written, 
does not currently treat the strength of signals between components, thus a 
slight modification was required to allow this test since the program would 
not know if the output signal from the valve was the result of one, two, or 
three pumps operating. The modification also allows the determination of the 
system status simply by checking the output process signal from the valve. 

The alteration made to the program for this test was made in line 
number 129 of the VALVE routine. By changing the test to require two input 
processes, the valve would not have an output unless at least two of the 
pumps are providing input to the valve. There are other ways this problem 
could have been modeled, but this method appeared to be the most 
straightforward. 

Unlike the previous two examples, this problem does not have a simple 
analytic solution for the time dependent unavailability. To simplify 
understanding of the test results, all pumps are chosen to be identical and 
the valve was modeled with failure and repair distributions identical to the 
three piamps . There are four components which can be in either a failed or 
operational state which means the system can be in 2^ — 16 possible states. 
Since all failure and repair rates are equal, in the asymptotic case each 
system state has equal probability of occurrence. Only four of the states 
correspond to the system being in an available condition, thus twelve states 
(or three fourths of the states) contribute to system unavailability. 
Clearly the asymptotic unavailability should be 0.75. 
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Two Out of Three Pumps 



Pump 1 




Fluid 

Supply 



Figure 4.6 Two Out of Three Piunps system Diagram 
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As in the previous two examples, the program was run for a simulated 
time period of 10,000 hours and for 100 Monte Carlo trials. Table 4.3 shows 
the fluctuation of unavailability about the desired value of 0.75. Again, 
the failure and repair distributions were chosen to be exponential with mean 
values of 100 hours. Figure 4.6 indicates that the system has reached its 
asymptotic state after approximately 200 hours. Thus the actual value for 
average system unavailability should be slightly less than the value of 0.75, 
which would be the exact result achieved for average system unavailability 
as time goes to infinity. This was also the case with the first two examples. 



Table 4.3 

Two Out Of Three Component Instantaneous Unavail eJaility 

TIME UNAVAILABILITY 



0.0 


0.0 


500.0 


0.72 


1000.0 


0.80 


1500.0 


0.76 


2000.0 


0.75 


2500.0 


0.78 


3000.0 


0.78 


3500.0 


0.73 


4000.0 


0.74 


4500.0 


0.66 


5000.0 


0.76 


5500.0 


0.68 


6000.0 


0.66 


6500.0 


0.77 


7000.0 


0.78 


7500.0 


0.71 


8000.0 


0.73 


8500.0 


0.67 


9000.0 


0.77 


9500.0 


0.71 


10000.0 


0.81 



The average value of unavailability over the 10,000 hour simulation was 
printed for each of the 100 trials and the resulting distribution is plotted 
in Figure 4.7. This figure indicates that the mean value of unavailability 
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TWO OUT OF THREE PUMPS & ONE VALVE 

(Ai = Ag = = /U.g = 0.01) 




Figure 4.7 Two Out Of Three Component 
Average Unavail eibility 
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is 0.7428 which agrees well with the expected value of slightly less than 
0.75, and it is seen that the standard deviation of the distribution is 0.03. 
This value of standard deviation is approximately half of that obtained for 
the first two example problems. 

The time dependent performance of this system is also of importance, 
thus a second run was done over a simulated time period of 200 hours using 
1000 Monte Carlo trials. The unavailability was sampled every hour to 
provide an accurate picture of the simulation program performance. For 
comparison, the Markov equations for the system were written. There are 
sixteen possible states and these are: 



Figure 4.8 shows the Markov state transition diagram for this system. All 
transition time distributions are the same and given by Xi = X 2 “ Ui “ 

U 2 - 0.01 per hour. 

Using these sixteen states the Markov equations for the system were 
written. These equations lead to a sixteen by sixteen matrix which is not 
a trivial problem to solve, therefore a fourth order Runge-Kutta numerical 
integration routine (from ref. P-4) was used to solve for the probability 
that the system is in any one of its sixteen states during the time interval 
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All components are good 

Pump #1 failed 

Pump #2 failed 

Pump #3 failed 

Valve failed 

P\amps #1 and #2 failed 

Pumps #1 and #3 failed 

Pump #1 and Valve failed 

Pumps #2 and #3 failed 

Pump #2 and Valve failed 

P\imp #3 and Valve failed 

Pumps #1, #2, and #3 failed 

Pvimps #1 and #2 and Valve failed 

Piamps #1 and #3 and Valve failed 

Ptunps #2 and #3 and Valve failed 

All Components are failed 
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Figure 4.8 Markov State Transition Diagram 
For Two Out of Three P\imp System 
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TWO OUT OF THREE PUMPS & ONE VALVE 




Figure 4.9 Two Out Of Three Component 
Time Dependent UnavailadDility 
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from zero to 200 hours. States 0, 1, 2, and 3 correspond to the system being 
available therefore the probabilities that the system is in any one of these 
four states is summed and subtracted from one to give the system time 
dependent unavailability. This exact solution is plotted in Figure 4.9 along 
with the simulation results for comparison. 

It is seen from Figure 4.9 that even for this more complicated system, 
the DYMCAM simulation program provides good results for the system time 
dependent unavailability. Again the fluctuation of the results about the 
desired result can be seen at larger time values and it is evident that the 
accuracy of Monte Carlo analysis is directly related to the number of trials 
performed. 

For this example problem, the computer time required to run the 10,000 
hour simulation run for estimation of the asymptotic unavailability value was 
approximately three hours on an IBM compatible XT running at 7.16 MHz . The 
second run to determine time dependent unavailability required four and one 
half hours. The significant increase over the time required for the first 
two tests is due to the fact that this problem is more complicated (sixteen 
system states as apposed to two or three) which leads to a far greater number 
of calculations to be performed during execution of the program. The 
difference between the two times required for the asymptotic run and the time 
dependent analysis run reflects on the fact that for more complicated 
systems, the number of Monte Carlo trials performed will have the 
controlling effect on the amount of time required to complete a computer run. 
Considering the fact that the accuracy of the results is dependent on the 
number of trials performed, it is evident that methods should be explored to 
reduce the amount of time required for a computer run. The DYMCAM code could 
probably be programed more efficiently. It was written to be as transparent 
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as possible and therefore may not be as efficient as possible, 

4.5 GO-FLOW Example Problem 

The fourth example problem considered will demonstrate the phased 
mission capability of the DYMCAM program. For comparison, this problem is 
derived from the GO-FLOW example problem discussed in reference M-2. The 
solution derived from the methods of reference M-2 will be used for 
comparison with the results of the simulation method. 

The problem to be solved involves a simple electrical circuit. Figure 
4.10 gives a diagram of the system. It is composed of a battery, having a 
demand failure probability of 0.1, which will supply power to two parallel 
circuits. Each circuit has a switch and a light bulb. The switches are 
identical and have a demand failure probability of 0.3. Neither the battery 
nor the switches are presumed to experience run time failures. The light 
bulbs in the system are considered identical and they have a 0.2 probability 
of failing on demand and an exponentially distributed run time failure rate 
with a mean value of one failure every 1,000 hours. 

The actual problem solved in reference M-2 considered that the switches 
had a probability of premature closure, however in the DYMCAM model this type 
of failure would be modeled as a run time failure and would mean that there 
is an equal probability that the switch could open once it is closed. Since 
the latter condition was not considered in reference M-2, the premature 
failure probability was excluded from the simulation analysis. A numerical 
solution was performed on the modified GO -FLOW problem to provide the 
comparison results. 

The phased mission problem to be solved considers that at time zero the 
battery is connected to the circuit and has a 0.9 probability of being good. 
A fraction of a second later one of the switches is closed, then ten hours 
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Figure 4.10 Light Bulb Problem Diagram 
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later the second switch is closed. The analyst wishes to determine the 
probability that at least one light is on immediately following closure of 
the first switch (call this time t-0.0), immediately prior to closing of the 
second switch (time t-9,99 hours), instantly following closure of the second 
switch (time t-10.0), and twenty hours after closure of the first switch 
(time t=“20,0). Analysis using the DYMCAM program was done varying the number 
of Monte Carlo trials from 1,000 to 10,000 to demonstrate a sensitivity 
analysis of the simulation method. 

To solve this problem using the DYMCAM program, the external event 
feature was used. This capability allows the input file to contain 
instructions which will cause a signal to change at an instant of time after 
the start of the simulation. This function was used to give the battery a 
process signal input at time t-0.0, to give the first switch a command signal 
to close at time t-0.0, and to give the second switch a command to close at 
time t-10.0 hours. This unique feature allows the DYMCAM program to easily 
solved phased mission problems. 

Tables 4.4 and 4.5 summarize the results of the ten tests run on the 
DYMCAM program. Table 4.4 shows the results using from 1,000 to 5,000 Monte 
Carlo trials and Table 4.5 shows the outcome of tests using 6,000 to 10,000 
trials. The tables show the actual probability of at least one light being 
on at each of the four designated time points as calculated using the GO- FLOW 
method and the corresponding values calculated with the simulation program. 
The difference of the simulation value from the actual value is shown and the 
percent error is calculated as the difference divided by the actual value. 
For an indication of the variance, the number of trials which would need to 
have been changed to give the actual results are indicated. For example, 
for the time point t=20 hours and for 1,000 trials. Table 4.4 indicates that 
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-10 trials would have to be changed. This means that 10 of the 1,000 trials 
for which a light was not on at t-20 would need to have had a light test on 
in order for the simulation results to agree with analytic results. 

Table 4.4 

Light Bulb Problem Results (1,000 to 5,000 trials) 



NUMBER OF TRIALS 



QUANTITY 


ACTUAL 


1000 


2000 


3000 


4000 


5000 


TIME 0.0 hours 
Result 


0.5040 


0.4910 


0.5070 


0.5057 


0.5033 


0.5020 


Difference from 





-0.0130 


0.0030 


0.0017 


-0.0007 


-0.0020 


actual value 
Equivalent number 





-13 


6 


5 


-3 


-10 


of trials 
Percent Error 


.... 


-2.6 


0.6 


0.3 


-0.1 


-0.4 


TIME 9.99 hours 
Result 


0.4990 


0.4880 


0.5025 


0.5010 


0.4985 


0.4968 


Difference from 





-0.0110 


0.0035 


0.0020 


-0.0005 


-0.0022 


actual value 
Equivalent number 





-11 


7 


6 


-2 


-11 


of trials 
Percent Error 


.... 


-2.2 


0.7 


0.4 


-0.1 


-0.4 


TIME 10.0 hours 
Result 


0.7236 


0.7060 


0.7270 


0.7320 


0.7275 


0.7266 


Difference from 





-0.0176 


0.0034 


0.0084 


0.0039 


0.0030 


actual value 
Equivalent number 


.... 


-18 


7 


25 


16 


15 


of trials 
Percent Error 


.... 


-2.4 


0.5 


1.2 


0.5 


0.4 


TIME 20.0 hours 
Result 


0.7191 


0.6980 


0.7205 


0.7257 


0.7215 


0.7212 


Difference from 





-0.0211 


0.0014 


0.0066 


0.0024 


0.0021 


actual value 
Equivalent number 


.... 


-21 


3 


20 


10 


10 


of trials 
Percent Error 


.... 


-2.9 


0.2 


0.9 


0.3 


0.3 



-5: 
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Table 4.5 

Light Bulb Problem Results. (6,000 to 10,000 trials) 



NUMBER OF TRIALS 



QUANTITY 


ACTUAL 


6000 


7000 


8000 


9000 


10000 


TIME 0.0 hours 
Result 


0.5040 


0.4995 


0.4950 


0.4971 


0.4998 


0.5007 


Difference from 





-0.0045 


-0.0090 


-0.0069 


-0.0042 


-0.0033 


actual value 
Equivalent number 





-27 


-63 


-55 


-38 


-33 


of trials 
Percent Error 


.... 


-0.9 


-1.8 


-1.4 


-0.8 


-0.7 


TIME 9.99 hours 
Result 


0.4990 


0.4935 


0.4889 


0.4913 


0.4939 


0.4948 


Difference from 





-0.0055 


-0.0101 


-0.0077 


-0.0051 


-0.0042 


actual value 
Equivalent number 


.... 


-33 


-71 


-62 


-46 


-42 


of trials 
Percent Error 


.... 


-1.1 


-2.0 


-1.5 


-1.0 


-0.8 


TIME 10.0 hours 
Result 


0.7236 


0.7238 


0.7204 


0.7205 


0.7214 


0.7243 


Difference from 





0.0002 


-0.0032 


-0.0031 


-0.0022 


0.0007 


actual value 
Equivalent number 


.... 


1 


-22 


-25 


-20 


7 


of trials 
Percent Error 


.... 


0.03 


-0.4 


-0.4 


-0.3 


0.1 


JTIME ,?0,0 hours 
Result 


0.7191 


0.7185 


0.7143 


0.7145 


0.7154 


0.7186 


Difference from 





-0.0006 


-0.0048 


-0.0046 


-0.0037 


-0.0005 


actual value 
Equivalent number 


.... 


-4 


-34 


-37 


-33 


-5 


of trials 
Percent Error 


.... 


-0.1 


-0.7 


-0.6 


-0.5 


-0.1 



It can be seen in these two tables that the error decreases as the 
number of trials is increased and for 10,000 trials the percent difference 
between the actual availability values and the estimates from the simulation 
program are less than one percent for all time points. As expected, there 
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is very little difference in the error percentages for two cases separated 
by only 1,000 trials. For example, there is an average of only a 0.5 percent 
difference between the values for the 3,000 trial case and the 4,000 trial 
case. The amount of error should decrease with increasing number of trials 
in proportion to one over the square root of the number of trials and this 
is evident by comparing the 1,000 and 10,000 trial cases. If the values of 
percent error at 1,000 can be taken to be characteristic of values that would 
be obtained regardless of the random number generator used by the program, 
then certain comments about the error can be made. For the four time points, 
the average error for 1,000 Monte Carlo trials is approximately 2.5 percent. 
The variance of the estimates should go as one over the square root of the 
number of trials, therefore it is expected that the percent error for 1,000 
Monte Carlo trials should be no greater than the square root of 1,000 divided 
by the square root of 10,000 times the error for the 1,000 trial case. 
Checking this assumption it is seen that the expected error should be no 
greater than 0.8 percent. From table 4.5 it is evident that this assumption 
is indeed correct and it seems probable that for any number of trials used 
greater than 10,000 the percent error of the result should be no greater than 
0.8 percent. However, to significantly reduce the error below this 0.8 
percent value using the current program would take a prohibitively large 
number of trials. In fact, using the above methods it is estimated that to 
reduce the error margin to 0.5 percent or less would require in excess of 
25,000 trials. 

The computer time required for these tests was approximately fifty 
minutes for every 1,000 trials, thus the 10,000 trial case took about eight 
and one half hours to run. This time requirement refers to an IBM compatible 
XT running at 7.16 MHz. The approximate time for the 10,000 trial on a 386 
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personal computer is estimated to be about 1.5 hours. Even at this rate, 
though, it would take computer runs of close to five hours to reduce the 
error to less than 0.5 percent for this particular problem with the current 
structure of the DYMCAM program. If more accurate solutions were necessary, 
it is clear that modifications to the program will be essential on order to 
reduce the computer time requirement, however, this kind of accuracy is 
almost never needed since there is always a inevitable amount of uncertainty 
in the original data. 

Demonstrated by this example was the important DYMCAM feature of using 
external events in phased mission analysis problems. GO-FLOW was designed 
with this capability, but most other methods do not provide an easy method 
for treating this type of problem. This capability can be exploited to 
analyze all types of systems involving testing and maintenance functions. 
4.6 Chapter Simmary 

In this chapter four example problems have been analyzed using the 
DYMCAM dynamic simulation model. A single component with exponential repair 
and failure distributions was considered to demonstrate program operation. 
Next, a third state was added to the component in the form of an 
exponentially distributed delay time between the failure and repair states. 
This example demonstrated use of the REPAIR. SUPERVISOR routine and the ease 
with which the program can be modified to meet specific needs. The third 
example considered a more complex problem and demonstrated that the program 
can model m-out-of-n components, although to do this properly the program 
should be modified to consider the strength of process variables. The final 
example treated a simple phased mission problem and illustrated the use of 
the external event concept to turn a component on after the start of a 
simulation time period. The results of all four examples were compared with 
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analytic answers and the comparison was favorable. In each case the 
simulation values agreed with expected results quite well. 

It was seen that the simulation method can be used to evaluate the 
as3rmptotic unavailability of a system, but more importantly, that it also 
provides good results for a time dependent unavailability analysis. Analytic 
asymptotic values agreed almost exactly with mean values of unavailability 
distributions produced. Time dependent simulation results agreed well with 
Markov solutions; however, differences between simulation and exact results 
do not vanish as the simulation proceeds. 

The DYMCAM program can be used for any type of phased mission problem 
where it is necessary to turn components on and off during a simulated time 
period. This capability was demonstrated with a very basic problem. This 
potential should prove very powerful in systems reliability analysis. Most 
current techniques are not designed for phased mission analysis. 

An important result observed was the importance of the program result 
accuracy on the number of Monte Carlo trials used and the time requirement 
necessary to achieve satisfactory results. A simulation technique such as 
this provides an estimate of the unavailability of a system. This estimate 
will have a distribution associated with it. The mean of the distribution 
should equal the exact analytical result, if one is obtainable, and the 
variance of the distribution is related to the number of trials performed. 
Thus, though the mean of the distribution may be equal to the exact solution 
after a small number of trials, there is no way of knowing this for certain 
unless the analytical solution is available. The variance of the 
distribution provides a measure of "confidence" in the mean value, thus to 
have increased confidence in the simulation result, it is desireable to have 
small variances. To accomplish this may require large amounts of computer 
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time . 

The DYMCAM program shows that it provides accurate results for simple 
problems . Further work should be done to modify the program to handle 
different levels of process signals and also to improve the speed with which 
the program runs. In the next chapter a problem involving a continuous 
process will be treated which involves modifying the program extensively and 
demonstrates the capability of simulation programs to treat continuously 
variable signals. 
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Chapter 5 

Continuous Simulation TAUK Progreun 
5 . 1 Introduction 

Most reliability analysis methods are designed to treat only systems 
which can be modeled using a discrete state space. This type of approach, 
however, may not be adequate for analyzing certain systems including process 
control problems which depend on continuous variables such as pressure, 
temperature, flow rates, and tank water levels. This particular type of 
problem has been discussed in detail by Aldemir in references A-1 and A- 2. 
Aldemir has developed a dynamic method which uses discrete Markov chains to 
model the probabilistic behavior of the system to analyze such problems, and 
in references A*1 and A* 2 he applies his technique to several examples 
including a process control system which regulates the water level in a tank. 

The DYMCAM dynamic simulation model discussed in previous chapters does 
not have the capability to treat failures of components whose state depends 
on a continuous variable such as water level. In this chapter the basic 
program is modified to include this capability. Although the TANK program 
developed here is designed specifically to solve the example problem treated 
in references A-1 and A- 2, it demonstrates the capability of the basic 
simulation approach to handle analysis of complex systems which involve 
continuous variables . 

The chapter begins with a section describing the problem to be solved. 
This problem is similar to the example treated by Aldemir in reference A-1. 
Aldemir treats the problem by considering the failure of the control system 
itself, which means that if a unit is in a failed state in one system control 
region, this does not mean the component will remain in that state if the 
process variable moves to another control region. The problem treated here 
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considers only the failure of individual input and output units. Thus once 
a component fails, it remains in that failed state regardless of any changes 
that may occur in the operating state of the system. Thus results should be 
different than those predicted by Aldemir. Once the problem is described, 
program modifications will be indicated which were necessary to simulate the 
example. As much as is possible the DYMCAM program is left exactly as it was 
in previous chapters and special subroutines and processes are added to treat 
the continuous variable. 

After the TANK program development is explained, the procedure is used 
to solve two of the cases discussed by Aldemir for the process control 
problem which controls a tank water level. Results are compared 
qualitatively with results in the reference. A simple Markov approximation 
to the system is also developed and results of the TANK simulation program 
are compared quantitatively to this solution method. For the simple case 
tested, results of the simulation model agree well with the approximate 
Markov modeling of the system and also with Aldemir' s solution. For the more 
complicated case tested, simulation results agree with Markov approximations 
but not with results proposed by reference A-1. Explanations are given for 
the difference. 

The TANK simulation program performs well on the specific problem 
tested and demonstrates the capability of a Monte Carlo simulation approach 
to be used in solving a continuous variable problem. 

5.2 Problem Description 

The problem to be solved consists of a fluid containing tank which has 
three separate level control units. Figure 5.1 shows a diagram of the 
system. Each control unit is independent of the others and has a separate 



level sensor associated with it. The level sensors measure the fluid level 
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Figure 5.1 Tank Problem Diagraim 
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in the tank, which is a continuous process variable, and based on the 
information from the level sensors, the operational state of the control 
units is determined. Each flow control unit can be thought of as containing 
a controller which turns the unit on and off based on the signal from the 
level sensors, as shown in Figure 5,1. Failure of the system occurs when the 
tank either runs dry or overflows. 

The tank has a nominal fluid level at the start of system operation of 
zero meters. The maximvim level of the tank is 3 meters (point b) and the 
minimum level of the tank is -3 meters (point a). If the tank level moves 
out of this range, failure of the system has occurred. Within this range 
there are two set points at -1 meter (set point alphal) and +1 meter (set 
point alpha2) . These set points define three control regions for system 
operation. Region one is defined from point a to alphal, region two is from 
alphal to alpha2, and region three is from alpha2 to point b. When the fluid 
level is in any of the three control region there is a specific action 
required of each of the three control units. Each control unit acts 
independently and is not aware of what the state of the other control units 
is except through the change occurring in the process variable. Table 5.1 
shows the control unit states for each control region. 

Table 5.1 

Flow Control Unit States as a Function of Fluid Level 



Control 

Region 


Liquid 


Control 


Unit 


State 


Level (x) 


Unit 1 


Unit 2 


Unit 3 


1 


x<alphal 


off 


on 


on 


2 


alphal<x<alpha2 


on 


on 


off 


3 


alpha2<x 


on 


off 


off 



Unit one is an outlet element providing a means for releasing fluid 
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from the tank to lower the level. In all cases discussed in reference A-1, 
unit one is assigned an exponential failure distribution with a mean failure 
time of 320 hours. This is the failure rate of unit one transferring to the 
wrong state. When operating the unit allows fluid to flow out of the tank 
at the rate of 0.01 meters per minute. Unit one receives a command from the 
level controller to be on when the fluid level is in control region two or 
three and it receives a signal to shut off when the fluid level is in control 
region one. If the unit is modeled as a valve, it is clear that the valve 
is normally open unless the fluid level is below the low level setting for 
the tank, in which case the valve is closed. The component routine used to 
model unit one as a valve is one of the routines contained in the basic 
DYMCAM program code . 

Unit two is a supply unit which provides fluid input to the tank. It 
too has an exponentially distributed failure rate which applies to unit two 
transferring to the wrong state. The mean failure time used for all cases 
considered in reference A-1 is 219 hours. When operating, the unit supplies 
fluid at the rate of 0.01 meters per minute. This unit receives a control 
signal to be on if the fluid level is in control regions one or two, and it 
receives a signal to shut off if the fluid level is in control region three. 
The unit can be modeled as a pump or an inlet valve. In this work the unit 
was treated as a valve. It is only necessary that the component model be 
able to fail open (on) or closed (off) and that it respond to control 
signals . 

The third unit is also a fluid supply element. It is identical in 
nature to unit two except that it has a mean failure time of 175 hours. 
Through most of the cases treated in reference A-1, the flow rate from unit 
three is identical to unit two therefore providing 0.01 meters per minute of 
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fluid, however in one of the cases (Case F of Ref. A-1) , which is also 
considered here, unit three only supplies 0.005 meters per minute of fluid. 
Unit three is normally in an off (closed) state unless the fluid level drops 
into control region number one, in which case the unit receives a signal to 
turn on. Like unit two this unit can also be modeled as an inlet valve as 
is done in the following analysis. 

At the start of system operation the fluid level is in the normal 
region (control region two) and units one and two are on while unit three is 
off. Thus the flow rate into the tank is equal to the flow rate out of the 
tank, and the fluid level is not changing. This state will continue until 
one of the level control units fails. Then the fluid level will change 
either up or down depending on which unit has failed, and when the fluid 
level enters a new control region the controller will take action to halt the 
change. The new system state may or may not be stable, as is seen later in 
the chapter, however failure of the system cannot occur with the failure of 
a single control unit. The level will remain in the new control region, or 
oscillating between two control regions until a second unit fails. The 
second failure is likely to cause the system to fail by the tank either 
running dry or overflowing. 

Since component repair is not considered in this problem, all scenarios 
will end in system failure. The type of failure experienced is dependent on 
the sequence in which the units fail and also upon the timing of failure for 
certain cases in which the fluid level oscillates. The problem to be solved 
in this reliability analysis is to determine the time dependent probability 
of each of the two types of failure. The complication which prohibits this 
type of problem from being easily solved by other analysis methods, is that 
component states are dependent on a continuous process variable. Modeling 
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of the process variable must be done, and a method must be available by which 
control units are allowed to change state at non- deterministic times. In 
other words the method of the DYMCAM program, which uses external events to 
control phased mission problems, is not appropriate since the time at which 
a component will be required to change its operating state will not be known 
before the simulation is begun. 

One characteristic of this problem does allow for a simple method of 
approximating the failure results. This is the relationship between unit 
failure time and the time required for the system to change from one control 
region to another once a unit has failed. The three units have mean failure 
times of 320, 219, and 175 hours respectively. If the tank fluid level is 
at zero when a unit fails, then at a flow rate of 0.01 meters per minute it 
will only take approximately 1.7 hours for the tank to change control 
regions. If the level is at the edge of control region one, and must travel 
to control region three, the longest amount of time that will be required is 
approximately 3.5 hours. If these times can be considered small enough so 
that the assumption can be made that a second failure does not occur until 
the system has entered a new control region, then a straightforward approach 
of initiating event analysis can be used and simple Markov chains can be 
applied to solve the problem. This approach is used as an approximate method 
against which the simulation results can be checked for an estimate of 
simulation performance. 

For the second case treated, in which the flow rate from unit three is 
reduced to 0.005 meters per minute, there are failure sequences which will 
lead to the fluid level changing at only 0.005 meters per minute. In this 
case the maximum time required to change from one control region to another 
is approximately 7 hours. Clearly the assumption that a second failure does 
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not occur during this transit time period is not as good for this case, and 
results using the approximate technique will not be as accurate. However, 
results are still expected to be quite good. 

5.3 The TANK Program - Modifications to DYMCAM 

The major change which was necessary to make in the DYMCAM program in 
order to solve the tank problem was to add a routine which models the 
continuous process variable, SIMSCRIPT II. 5 has a continuous variable 
modeling capability , which is described in reference F-1, and this was used 
to treat the fluid level in the tank. This new variable required the 
addition of several subroutines to the DYMCAM program and these are described 
in this section. In addition, certain subroutines of the original program 
required minor modification. Table 5.2 lists all the new subroutines added 
and all the old subroutines to which adjustments were made. A complete 
SIMSCRIPT program listing of the new subroutines is contained in Appendix C. 
The modified subroutines are contained in Appendix B, In Appendix B, those 
subroutines which were modified for the tank problem contain the message 
"TANK" at the far right hand side of the page next to the added or altered 
lines of code. These commands should be removed or altered to use the DYMCAM 
program by itself. It should be emphasized that the sole purpose of the 
particular modified program is to demonstrate a simulation modeling approach 
to a reliability problem involving continuous process variables. 
Modifications made to the DYMCAM program have been chosen with an eye on 
rapid implementation rather than programming generality. 

The most fundamental addition to the program was the TANK process. 
This is the continuous process which provides SIMSCRIPT with the capability 
to solve continuous variable systems. The continuous capability of SIMSCRIPT 
II. 5 is described in detail in reference F-1 by Fayek. The difference 
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between discrete and continuous event simulation is fundamental. In purely 
discrete event simulation the model advances in time from event to event 
using entries in an event queue. It is assumed that the system remains 
unchanged between scheduled events and can change only at the designated 
event times. For a continuous model, variables are assumed to vary 
continuously with advancing time. Thus time is incremented by a small amount 
and all variables are updated. This is done by associating a differential 
equation with each continuous variable which indicates the rate of change for 
that variable. Then as time is advanced by discrete time steps, integration 
is performed to update the status of the continuous variable at the end of 
each time step. 



Table 5.2 



Subroutine 



TANK Subroutines 



Description 



Modified DYMCAM Routines 
PREAMBLE 

MAIN 

CALL. UPDATE 
RUN. INITIALIZE 
SYSTEM. UPDATE 



Modified to reflect new variables 
and processes 

Modified to Initialize and stop 
the Tank 

Modified to start Tank process 
Modified to add signals 
Modified to update flow rates 



New. Routines 

FLOW. UPDATE 

STOP . TANK 

TANK 

TANK. CONDITION 
TANK. INITIALIZE . RUN 
TANK . INITIALIZE . TRIAL 
TANK. UPDATE 
WATER. LEVEL 



Routine to calculate flow to and 
from Tank 

Process to reset Tank after each 
trial 

Continuous process to monitor fluid 
level 

Function that checks for proper 
control region operation 
Routine to initialize all variables 
and sets for the Tank 
Routine to re- initialize specific 
variables for next trial 
Routine to track System status and 
control all units 
Routine providing integration 
quantity for continuous 
routine 
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SIMSCRIPT II. 5 uses a variable time step for which the user must 
specify the minimum and maximum to be allowed. The integration routine can 
be specified explicitly, or the Runge-Kutta integration routine which is 
contained in the SIMSCRIPT language may be used. Also associated with the 
integration routine are error parameters must be indicated to specify the 
accuracy of integration calculations desired. All of these initializations 
were entered in the TANK. INITIALIZE. RUN routine. 

Figure 5.2 shows a flow chart of the operation of the TANK program. 
Following through this chart will provide an explanation of the TANK program 
operation and methodology. The function of routines of the DYMCAM program 
will not be repeated here since they are described in Chapter 3. 

The tank begins with the TANK. INITIALIZE. RUN routine which creates and 
initializes the variables and signals associated with the tank. This is done 
only once at the beginning of each computer run. Next, for every trial the 
tank output signals, the tank level, and the initial flow rate are reset by 
the TANK. INITIALIZE. TRIAL routine. After all other initialization is 
completed by the DYMCAM program, the simulation clock is started. Failure 
of all three units will be scheduled to occur at discrete times in the 
simulation based on their failure rates, and these times are assigned by the 
DYMCAM program. 

Unlike the DYMCAM program, which uses only discrete event simulation, 
the TANK program also contains the continuous tank level variable. Thus 
after the start of the simulation, control of the time aspect of the program 
is performed by the Tank process. This subroutine contains the statement 
(line 15): 

work continuously evaluating 'water . level ' testing ' tank. condition' 
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Figure 5.2 Flow Chart of TANK Program 
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This statement updates the tank water level using the WATER. LEVEL routine 
which applies the differential equation: 

d. level (tank) - net . flow. rate (tank) 

The time step is variable between the minimum and maximum specified by the 
user and in this case, is not variable since both values were set equal to 
one hour. If a variable time step were allowed, then SIMSCRIPT would adjust 
the step based on how fast the variable is changing. The integration 
routine, Runge-Kutta in this case, calculates the water level at the new 
time . 

Once the new level is determined, the TANK. CONDITION routine is called 
to verify that the tank condition is good. If it is, then the simulation 
clock is advanced another time step, and the new water level is calculated. 
If the TANK. CONDITION routine determines that: 1) the net . flow. rate (tank) 
does not equal the flow. rate, in minus the flow. rate . out , 2) the tank has 
failed by overflow or dryout, or 3) The control state is not correct based 
on the current fluid level; then continuous time steps are stopped and 
control continues in the TANK process. The net flow rate for the tank is 
updated here next. The reason for this is to provide proper synchronization 
for changing of the flow rate. After updating the net flow rate, the TANK 
process calls the TANK. UPDATE routine. 

The TANK. UPDATE routine serves two functions. First it checks the 
water level to see if overflow or dryout has occurred. If either condition 
has occurred, then the output signal from the tank, indicating tank status, 
is set equal to zero (representing tank failure), and control is returned to 
the Tank process. The TANK process then suspends itself. The rest of the 
simulation time of the trial passes in discrete event fashion. When the 
scheduled STOP. TANK and STOP . SIMULATION times are reached, the TANK process 
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is reset and the next trial begun. It should be noted that the system 
indicator variable can have only one of two values indicating either system 
success or failure. Since both tank overflow and tank dryout are failure 
events, it is necessary to simulate failure in each mode separately. This 
is done by altering the computer code to count only failures of one type or 
the other during a particular run of the program. To test for the 
probability of tank overflow, lines 13 through 17 of the TANK. UPDATE routine 
were rendered un- executable , and when testing for tank dryout, lines 13 to 
17 were restored and lines 24 through 28 of the Tank. Update routine were 
removed. In either case, once the tank has run dry or overflowed, continuous 
operation of the system is suspended. Of course, an alternate modification 
is to revise the SYSTEM. UPDATE and RUN. OUTPUT routines such that multiple 
output states are recognized. This was felt to be more complex than the 
method adapted. 

If the tank has not failed, then the TANK. UPDATE routine checks to see 
if the unit control states are correct based on the fluid level of the tank. 
If not, the TANK. UPDATE routine creates the proper control signals to send 
to the three units to change their operating state to the proper condition. 
To cause the units to change state, the SYSTEM. UPDATE routine is called. 
This is a DYMCAM routine which changes the states of components based on 
changes in signals and on changes in other system component states. A new 
line added to the SYSTEM. UPDATE routine for the TANK problem, appears at line 
141. This command causes the FLOW. UPDATE routine to be called. This routine 
calculates the flow rate going into the tank and the flow rate coming out of 
the tank based on the state of the three control units. It does not directly 
calculate the net flow rate into the tank which is used by the WATER. LEVEL 
routine. This is done in the TANK process to prevent the flow rate from 
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changing during an integration time step. 

Once the flow rates are updated, control is returned to the 
SYSTEM. UPDATE routine. The SYSTEM. UPDATE routine, in turn, returns control 
to the Tank. Update routine. Now the tank is in the proper operating 
condition and thus control is returned to the TANK process. Since the tank 
has not yet overflowed or run dry, the TANK process begins execution of the 
continuous function again. Time is advanced by the given time step (one 
hour) , the level of the tank is updated, and the condition of the tank is 
again checked. As long as the tank condition is good, operation continues 
in this fashion. If the tank condition tests bad, then the continuous 
operation is again suspended. 

The failure rates used for the three control units in the tank problem 
make it highly likely that the system will fail during the simulated 1,000 
hour time period, therefore at some point the continuous process should stop 
and the simulation will continue in the discrete event fashion. In the rare 
case of no system failure during the 1,000 hour period, the continuous 
process will be suspended by the Stop. Tank routine at the 1,000 hour time 
point, and the system will be reset for the next trial. Of course, no 
failure event would be recorded for such a trial. 

Individual control unit failures are controlled by the DYMCAM program. 
When a failure occurs, the SYSTEM. UPDATE routine is called which in turn will 
cause the flow rate into and out of the tank to be adjusted. This change 
will effect the TANK program when the TANK. CONDITION routine detects that the 
net flow rate to the tank does not equal the flow rate in minus the net flow 
rate out, and as described above, the continuous operation will be 
Interrupted while the net flow rate is changed by the TANK process. 

The new routines, TANK. INITIALIZE .RUN and TANK. INITIALIZE .TRIAL are 
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Figure 5.3 TANK Program Signals 
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used to initialize all the parameters associated with the test. Most 
importantly the TANK. INITIALIZE. RUN routine creates all of the output signals 
associated with the tank. Since the DYMCAM program does not recognize the 
tank as being a component, it is not assigned any output signals. Thus one 
line is added to the DYMCAM RUN. INITIALIZE routine (line 51) to add five 
signals to the total system signal count. Figure 5.3 shows all of the signal 
associated with the TANK program. The five new signals are indicated by 
stars. These signals are then initialized by the TANK. INITIALIZE. RUN 
routine. Once created, the signals are treated in the same manner as all 
other component signals. The five signals concerned are the three control 
signals from the tank to each of the three units, the output process flow 
from the tank to unit one, and a system status signal to indicate system 
success or failure. 

The TANK. INITIALIZE. RUN routine also creates the signal and component 
files necessary for clean operation of the program code. The 
TANK. INITIALIZE. TRIAL routine, which is executed prior to each trial, resets 
the net flow rate to zero, sets the tank fluid level back to zero, turns the 
flow out of the tank on, resets the system success indicator to "good," and 
turns off the command signals to all three control units. 

The STOP. TANK process operates in much the same fashion as the 
STOP. SCENARIO process. It is used to suspend operation of the tank, if the 
tank has not failed during the simulated time period (which has a very low 
probability of occurrence) , and then to reset the tank so it is ready to be 
started at the beginning of the next Monte Carlo trial. 

Minor modifications were also made to the MAIN routine and the 
CALL. UPDATE process of the DYMCAM program. The MAIN routine was modified to 
include calling the tank initialization routines and to call the STOP. TANK 
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process. In addition the availability data structure was modified to print 
out the desired results in the output file. The CALL. UPDATE process was 
revised to include lines 14 and 15 which simply take the tank out of its 
suspended state and cause it to start operation at the beginning of every 
trial. 

In addition, many lines were added to the PREAMBLE to reflect all of 
the new routines, processes, and variables associated with the TANK program. 
These lines are indicated in the Preamble listing for the DYMCAM program in 
Appendix B by the marker "TANK" which is placed at the far right hand side 
of each line of code which was modified or added. The entire TANK program, 
as a unit, was compiled and kept separate from the DYMCAM program, since 
subroutines cannot be compiled separately, and the two codes are not used 
together. They do, however, contain the Scime basic structure and the TANK 
program should be viewed as an extension of the DYMCAM program, which remains 
almost entirely intact in the TANK code. 

The input file necessary to run the program is exactly the same format 
as the input file for the DYMCAM program described in Appendix A. The only 
point to note is that the three units were modeled as valves in the 
simulation program. It is also important that the names of the level control 
units be entered as unitl, unit2, and unit3 so that they are recognized by 
the TANK program as the flow control units. An example input file for this 
program is contained in Appendix D. The same input file is used for all 
tests, and changes are made in the program to reflect testing for the failure 
condition of overflow or dryout and to alter the flow rate provided by unit 
three. The output file generated by the TANK program is identical in format 
to the output generated by the DYMCAM program, and an example print out is 
shown in Appendix E. 
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5.4 TANK Results 

Two example cases were considered in the testing process. In the 
notation of reference A-1, Case A involves unit three having a flow rate of 
0.01 meters per minute and in Case F the flow rate from unit three is changed 
to 0.005 meters per minute. Otherwise the test cases are exactly the same. 
The change made to reflect the different flow rate is made in the FLOW. UPDATE 
routine. To test for the probability of tank overflow, lines 13 through 17 
of the TANK. UPDATE routine were rendered un-executable, and when testing for 
tank dryout, lines 13 to 17 were restored and lines 24 through 28 of the 
Tank. Update routine were removed. This method was used to test for the 
selected type of failure event, since both tank overflow and dryout are 
failures and should not be counted together as failures during the same test 
run. 

As explained earlier, if failures can be assumed to be separated by at 
least 3.5 hours in Case A and 7 hours in Case F, then it is possible to use 
a Markov chain to approximate a solution to the problem. This approach 
involves understanding the feasible failure sequences which can occur in each 
case. An understanding of the failure sequences also provides insight into 
the problem solution by simulation methods, so they will be described in 
detail . 

5.4.1 Analysis of Case A 

For Case A the tank starts at time zero with all units operational, and 
units one and two turned on, and unit three turned off. The tank will 
continue in this state with no change in the tank level until a failure of 
a control unit occurs. The sequencing of failure is very important so each 
unit failing first will be considered separately. Figure 5.4 shows the state 
transition diagram for this system. All states are defined in Table 5.3. 
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Tank Case A 




Figure 5.4 Tank Case A state Transition Diagram 
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Thus the three possible initiating events are unit one or unit two failing 
closed, or unit three failing open as shown in Figure 5.4. Since the unit 
which fails first is only dependent on the failure rates of the three units, 
it seems intuitively clear that the probability of each individual unit being 
the first to fail is given simply by the ratio of the failure rate for that 
unit divided by the sum of the failure rates for all three units. 

To show this more formally, consider the system composed of only the 
first four states of Figure 5.2, states 0, 1, 2, and 3. The four Markov 
equations for this system are: 



dPn 

“dt " "[^1 ^2 ^ 3 ] ^0 



dP, 



di 



dt ■ "'10 
dP 

± = \ p 

dt ^^2^0 



(5.1) 

(5.2) 

(5.3) 

(5.4) 



Noting that at time t-0.0 the system is initially in state 0 giving 
Po(0)-1.0, equation 5.1 can be solved to give: 

P^(t) = exp|^-p^ -^2 

Substituting this result into equation 5.2 gives: 

dP, 

"dt = ^1 «^p[-[^i * ^2 ^ ^3]"] 



(5.6) 
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which can be solved to yield; 

-^1 



where C = 
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exp 
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c, 



(5.7) 



The equation for state 1 can therefore be written: 



P^(t) = 



PI 
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1 - 



exp [-[, 
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Using the same solution approach for states 2 and 3 it is found; 



P2(t) = 



p—TT^-g- 

Ao 






|l - exp (5.9) 

|l - exp '^ 3 ]^]} (5.10) 



Solving equations 5.8, 5.9, and 5.10 for t sufficiently large, it is clear 
that: 
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^3] 



Using these results it is found that unit three will fail first 43% of the 
time, unit two 34%, and unit one 23% of the time. 

The initial failure of unit one is the easiest case to consider since 
it will always lead eventually to a tank overflow condition, regardless of 
the relative flow rates provided by the three units. Unit one failing closed 
causes the fluid level to rise until it passes into control region number 
three, at which time unit two is shut off. The tank remains in this 
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condition until either unit two or unit three fails open, either of which 
will lead directly to a tank overflow condition. 

The initial failure of unit two poses a more interesting problem. With 
\anit two failing closed, the fluid level will drop until it reaches control 
region number one. Then unit one is closed and unit three is opened. This 
causes the fluid level to rise until the fluid level is in control region two 
again, at which time unit one is opened and unit three is closed. Thus the 
fluid level will continue to oscillate about the low level set point of -1 
meters with units one and three being alternately turned on and off. The 
continuous routine in SIMSCRIPT uses a finite but variable time step, the 
minimum and maximum of which must be specified by the programer. For both 
cases considered, the minimum and maximum time steps were both set equal to 
approximately one hour, therefore for this case the level of the tank will 
fluctuate between -0.4 meters and -1.6 meters, spending equal time in each 
of the two control regions (one and two). This is true since while the level 
is rising, the rate of increase is 0.01 meters per minute, and while the 
level is falling the rate of level change is also 0.01 meters per minute. 
Fluctuation occurs between the same two points since time steps were forced 
to be constant at one hour intervals. 

From this state there are four possible events which can occur. While 
the fluid level is rising, unit one can fail open or unit three can fail 
closed, or while the fluid level is decreasing unit one can fail closed or 
unit three can fail open. It is clear that if either unit fails while the 
level is rising the flow rates in and out of the tank will then be equal and 
the fluid level will stop changing until the failure of the third level 
control unit. This third failure will lead directly to the tank running dry. 

If one of the two control units fails while the tank level is dropping 
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then, again, the tank fluid level will cease to change until the failure of 
the third xmit. This time, the third unit failing will lead directly to 
overflow of the tank. Since the tank spends an equal time in the rising and 
falling level states, it is equally likely that the tank will fail in an 
overflow or dryout state. Thus for the case of unit two being the initial 
failure event, there is a 50% probability that the tank will fail in each of 
its two failure conditions. 

For the case of unit three failing first, the solution is as easy as 
for unit one failing first. When xinit three fails open the fluid level will 
begin to rise until the level has reached control region number three at 
which time unit two will be closed. Now with both units one and three open 
the fluid level will hold constant at 1 meter. The next failure event, 
either unit one failing closed or unit two failing open, will lead directly 
to a tank overflow condition. Thus for all scenarios where unit three fails 
first, the tank will fail by overflow. 

From the above discussion it is evident that all unit one initial 
failures, all unit three initial failures, and half of the unit two initial 
failures will eventually lead to an overflow condition. Thus using the 
values quoted above for the probability that each of the three units will 
fail first, it. is found that the probability that the tank will fail by 
overflow is ; 

0.23 + 0.43 + (0.5 * 0.34) - 0.83 

The tank will fail by overflowing approximately 83% of the time and fail by 
running dry the other 17% of the time. 

It is important to note that although the above method simplifies the 
problem so that it may be solved with Markov chains without even considering 
the continuously variable tank fluid level, this method is only an 
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approximation and is as good as the assumption that two failures do not occur 
within a 3.5 hour time period. This, of course, will not be the case for all 
continuous variable process control problems. In this example problem the 
results obtained using the approximation agree well with the simulation 
results, but several possible failure sequences which will occur with low 
probability are ignored. For example, consider the case of failure of both 
units two and three within 1.5 hours of each other. This will leave the 
fluid level essentially unchanged or, at least, still in control region 
number two. The net flow rate from the tank is still zero so the tank will 
remain in this condition until unit one fails, at which time the tank will 
overflow. If it is considered that unit three fails just prior to unit two, 
then the result is consistent with the approximate analysis. However if unit 
two failed first, then the approximate method predicts that half the cases 
will experience system failure by overflow and half will be by dryout. This 
is obviously not the case for the dual failure example and the approximate 
solution will be slightly in error. Other "simultaneous" failures lead to 
similar conclusions. 

5.4.2 Analysis of Case F 

For Case F the problem becomes much more complicated. The initial 
failure probabilities remain unchanged from Case A, but some of the sequences 
of events after initial failure change. One part that remains the same, 
however, is the scenario following initial failure of unit number one. Since 
unit one is the only way fluid can be removed from the tank, once it has 
failed closed the tank is guaranteed to fail by overflow. Thus as in Case 
A, if unit one fails first, all scenarios lead to overflow. The time to 
overflow, however, could be different due to the different flow rate from 



unit three. 
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If unit two fails first, the tank level drops to the low set point and 
begins to oscillate above and below this mark as units one and three are 
opened and closed (as in Case A). However, the amount of time spent in each 
control region will be different. When the fluid level is rising, unit one 
is closed and unit three is open, thus the level is changing at the rate of 
0.005 meters per minute. When the level is falling, unit one is open and 
unit three is closed, thus the level is changing at 0.01 meters per minute. 
Define the flow rates from each of the three units as x^, X2, and X3 

respectively. For Case F the normal values are, x^-O.Ol, X2=-0.01, and 
X3- 0.005 meters per minute. Since unit two has failed closed, then X2-O.O. 
Define the net flow rate as x„et» then while the water level is in control 
region one (and unit one os closed), x^g^ is given by: 

^et - X 3 - 0.005 

While the water level is in control region two (and unit three is closed) , 
x„,t is given by: 

>^et - -Xi - -0.01 

Therefore, if the tank level is considered to vary between the same two 
levels, the tank must spend twice as much time in the control region one 
(with unit three open and one closed) , than in the control region two (with 
one open and three closed). This will reflect in the failure scenarios. 

If while the tank level is increasing, either unit fails, then the tank 
will immediately run dry. This is the same result as for Case A except that 
Case A would not experience dryout until all three units have failed. If 
while the tank level is decreasing, unit one fails, then the tank level will 
hold constant until unit three fails open. Then the tank will overflow. 
This sequence is the same as for Case A, however overflow will occur a few 



hours later due to the slower flow rate from unit three. 
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The fourth possible failure sequence resulting from the initial failure 
of unit two is entirely different. If unit three fails while the tank level 
is decreasing, then the level will continue to decrease until the level 
reaches control region one, since the flow through unit three is half the 
value of the flow through unit one. Once in control region one, unit one is 
closed and the level will rise because of the flow from failed unit three. 
Once the level is again in control region two, unit one will be opened. 
Thus the level oscillates about the -1 meter level with equal time spent 
while the tank level is rising and falling due to the fact that the flow rate 
from unit one is exactly twice that from unit three. Since unit two has 
failed closed and unit three has failed open, X 2 - 0.0 and X 3 =» 0.005. While 
the water level is in control region one, unit one is closed; Xjjat is given 
by: 

>^et - X 3 - 0.005 

While the water level is in control region two, unit one is open thus x^j^^ 
is given by: 

- X 3 - Xi - 0.005 - 0.01 - -0.005 
The water level rises and falls at equal rates. 

From this condition, unit one can either fail open or closed depending 
on whether it fails while the tank level is rising or falling. These 
failures occur with equal probability. Therefore, once units two and three 
have failed there is an equal chance that the tank will run dry or overflow. 

Summarizing the possible sequences following failure of unit two it is 
seen that the probability of subsequent failure of unit one or three is equal 
to the ratio of their failure rates to the svim of the failure rates. Thus 
there is a 65% chance that the next failure will be of unit three and a 35% 
chance that the next failure will be of unit one. Of these percentages, two 
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thirds of the unit one failures will be unit one failing open, which leads 
directly to dryout, and the other one third of the unit one failures lead to 
eventual tank overflow. For the unit three failure cases, two thirds will 
be unit three failing closed, while the fluid level is rising, and this leads 
to the tank failing by dryout. The other one third lead to oscillation in 
the fluid level with unit one opening and closing, thus 50% will lead to 
eventual system overflow and 50% will lead to system dryout. Evaluating the 
probabilities of the scenarios initiated by the failure of unit two, it is 
found that 77% lead to tank diryout while 23% lead to tank overflow. Figure 
5.5 shows the state transition diagram for the Case F tank problem. 

In Case F it is also no longer true that the initial failure of unit 
three will eventually lead to tank overflow. To see this, the scenarios 
associated with the initial failure of unit three are analyzed. Following 
failure of unit three the tank level rises into control region three and then 
unit two is closed. Since the flow rate from unit one is greater than the 
flow rate of unit three, the level drops into control region two, at which 
point unit two is turned back on. Thus the fluid level oscillates about the 
+1 meter level with unit two being opened and closed. While unit two is on, 
the net flow rate into the tank is 0.005 meters per minute, and while unit 
two is off the flow rate out of the tank is 0.005 meters per minute, thus if 
the tank level is assumed to oscillate between the same two levels, the 
system spends equal time with unit two open or closed. 

The next failure of either unit one or two will again be in proportion 
to the failure rates associated with each unit. Using these values it is 
found that subsequent to failure of unit three , there is a 41% chance that 
the next failure will be of unit one and a 59% chance that the next failure 
will be of unit two. If unit one fails, it closes, thus the tank will go 
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immediately to the overflow condition. Since unit two spends fifty percent 
of its time open and fifty percent of its time closed, it has an equal 
probability of failing either closed or open. 

If while the tank level is decreasing, unit two fails on, the tank will 
go directly to an overflow state. If, however, unit two fails closed while 
the tank level is increasing, then the tank level will fall until it is in 
control region one, at which time unit one will be closed. Then the level 
will rise due to flow from unit three until the level is in control region 
two, when unit one will be opened again. Thus the level oscillates about the 
-1 meter level with unit one opening and closing. 

The flow rate when fluid is leaving the tank is the same as the flow 
rate when the fluid level is rising, therefore unit one spends an equal 
amount of time open and closed. If unit one fails closed while it is open, 
then the tank will overflow. If unit one falls open while it is closed, then 
the tank will run dry. The latter case was not possible in Case A. 

Table 5.3 

Case A Failure Sequence Summary 



Failure Sequence Probability Result 



#1 


closed, #2 open 




0.10 


overflow 


#1 


closed, #3 open 




0.13 


overflow 


#2 


closed, #1 closed. 


#3 open 


0.06 


overflow 


#2 


closed, #1 open, #3 


closed 


0.06 


dryout 


#2 


closed, #3 open, #1 


closed 


0.11 


overflow 


#2 


closed, #3 closed. 


#1 open 


0.11 


dryout 


#3 


open, #1 closed 




0.17 


overflow 


#3 


open, #2 open 




0.25 


overflow 



Summarizing the scenarios following the initial failure of unit three 
it is seen that all but one of the situations leads to a tank overflow 
condition. If unit one fails second, then overflow is certain to occur while 
if unit two fails second only three quarters of the time will overflow occur. 
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Evaluating numerically, following the initial failure of unit number three, 
there is a 35% chance that the tank will fail by overflow and only a 15% 
chance that the tank will run dry. 

Table 5.4 

Case F Failure Sec[uence Summary 



Failure Sequence Probability Result 



#1 closed, #2 open 


0.10 


overflow 


#1 closed, #3 open 


0.13 


overflow 


#2 closed, #1 open 


0.08 


dryout 


#2 closed, #1 closed, #3 open 


0.04 


overflow 


#2 closed, #3 open, #1 closed 


0.04 


overflow 


#2 closed, #3 open, #1 open 


0.04 


dryout 


#2 closed, #3 closed, #1 open 


0.15 


dryout 


#3 open, #1 closed 


0.17 


overflow 


#3 open, #2 open 


0.13 


overflow 


#3 open, #2 closed, #1 open 


0.06 


dryout 


#3 open, #2 closed, #1 closed 


0.06 


overflow 


Compiling the results of all initial 


failure events 


and evaluating the 



numerical results it is found that for Case F, the probability that the tank 
will fail by running dry is 0.30 and the probability that the tank will fail 
by overflowing is 0.70. Thus in Case F the tank is more likely to fail by 
running dry than in Case A due to the decreased flow rate from unit three . 
Table 5.3 summarizes the possible failure sequences for Case A, their 
probability of occurrence, and the end result. Table 5.4 summarizes the same 
results for Case F. 

5.4.3 Simulation Analysis 

The results obtained for the asymptotic failure probabilities agree 
well with the simulation results, as shall be seen, and Case A coincides with 
the results presented by Aldemir in reference A-1. For Case F, however, 
results from the simulation method agree with results from the simplified 
Markov model, but not as closely with Aldemir 's predictions. This is due to 
the fact that the problem treated in this work considers the failure of 



V 



\ 

f 










Iii.i 



Dynamic Simulation Model 



150 



components and Aldemir considers failure of the control system for the 
components. Thus there will be different failure possibilities between the 
two approaches. 

From the above initiating event analysis, and making the assumption 
that the time required for the fluid level to transit between control regions 
is negligible, it is possible to construct Markov chains to approximate the 
time dependent behavior of the system. Figure 5.4 shows the Markov state 
transition diagram for Case A and Indicates that sixteen states are required. 
Figure 5.5 shows the state transition diagram for Case F, which requires 
nineteen states. Table 5.5 shows the states used for Case A and their 



corresponding definition. States 11 and 13 correspond to tank dryout while 
states 4, 5, 10, 12, 14, and 15 correspond to tank overflow. From the states 
in this table the Markov equations are written using the failure rates for 
each, control unit. The Markov equations are shown in Table 5.6. 

Table 5.5 



STATE 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 



Markov States for Tajik Case A 

FAILURE DESCRIPTION 



All units good 
Unit 1 failed closed 
Unit 2 failed closed 
Unit 3 failed open 
Unit 1 failed closed then Unit 2 failed open (Overflow) 



failed open (Overflow) 
failed closed 
failed open 
failed open 
failed closed 
failed closed then 



Unit 1 failed closed then Unit 3 
Unit 2 failed closed then Unit 1 
Unit 2 failed closed then Unit 1 
Unit 2 failed closed then Unit 3 
Unit 2 failed closed then Unit 3 
Unit 2 failed closed then Unit 1 

Unit 3 failed open (Overflow) 

Unit 2 failed closed then Unit 1 failed open then 
Unit 3 failed closed (Dryout) 

Unit 2 failed closed then Unit 3 failed open then 
Unit 1 failed closed (Overflow) 

Unit 2 failed closed then Unit 3 failed closed then 
Unit 1 failed open (Dryout) 

Unit 3 failed open then Unit 1 failed closed (Overflow) 
Unit 3 failed open then Unit 2 failed open (Overflow) 
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Tank Case F 




Figure 5.5 Tank Case F State Transition Diagreun 
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Table 5.6 

Markov Equations for Tank Case A 



0 ^ 
dt 

dt 

dt 

dt 

dt 

dt 

dt 

dt 

dt 

dt 
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TANK PROBLEM 
CASE A - DRYOUT 




Figure 5.6 Case A - cumulative Dryout Probability 
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TANK PROBLEM 
CASE A - OVERFLOW 




TIME(hours) 



Figure 5.7 Case A - Cumulative Overflow Probability 
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The failure rates are defined in reference A-1 as: 

Unit 1: = 5.2 ♦ 10 ^ per minute 

Unit 2: A 2 = 7.6 * 10 ^ per minute 

Unit 3: A^ = 9.5 * 10 ^ per minute 

To solve these equations, a fourth order Runge-Kutta numerical 

integration routine (obtained from ref. P-4) was used as in Chapter 4. The 
time period of concern is from time zero up until approximately 1,000 hours. 
The time dependent results for appropriate states were summed to obtain the 
time dependent probability of system failure by overflow or by dryout. 

The TANK program was run for a simulated time duration of 1,000 hours 
and 1,000 Monte Carlo trials were performed. The results were then plotted 
along with the Markov approximation for comparison. Figure 5.6 shows the 
time dependent results for the tank running dry and Figure 5.7 shows the 
results for the tank failing by overflow. Both of these figures indicate 
good agreement between the simulation results and the Markov approximation. 
The time dependent behavior is virtually Identical and values differ by only 
a few percent. Good agreement between the simulation results and the 
simplified Markov model is expected since the time required for the tank 
level to change is small in comparison with the failure times associated with 
the individual flow control units. A quantitative comparison of the 
simulation and simplified Markov results with the numerical results provided 
by Aldemir's dynamic Markov approach for Case A is shown in Figure 5.10, 
The data for Aldemir's approach was provided in reference A- 5, and is the 
same as the results presented in reference A-1. The figure indicates that 
the simplified Markov results agree almost exactly with Aldemir's predictions 
and the simulation method provides results which are very similar to both. 
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For this case, the difference between the three methods is very small and 
indicates that although the approach to the problem was different for each 
method, the results were quite comparable. 

For approximate analysis of Case F using the Markov technique, there 
are nineteen states of interest. These states are listed in Table 5.7 below. 
States 6, 12, 13, and 17 contribute to tank dryout while states 4, 5, 10, 
14, 15, and 18 contribute to tank failure by overflow. 

Table 5.7 

Markov States for Tank Case F 



STATE FAILURE DESCRIPTION 



0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 



failed open (Overflow) 
failed open (Overflow) 
failed open (Dryout) 
failed closed 
failed open 
failed closed 
failed closed then 



All units good 
Unit 1 failed closed 
Unit 2 failed closed 
Unit 3 failed open 
Unit 1 failed closed then Unit 2 
Unit 1 failed closed then Unit 3 
Unit 2 failed closed then Unit 1 
Unit 2 failed closed then Unit 1 
Unit 2 failed closed then Unit 3 
Unit 2 failed closed then Unit 3 
Unit 2 failed closed then Unit 1 

Unit 3 failed open (Overflow) 

Unit 2 failed closed then Unit 3 failed open then 
Unit 1 failed closed (Overflow) 

Unit 2 failed closed then Unit 3 failed open then 
Unit 1 failed open (Dryout) 

Unit 2 failed closed then Unit 3 failed closed then 
Unit 1 failed open (Dryout) 

Unit 3 failed open then Unit 1 failed closed (Overflow) 

Unit 3 failed open then Unit 2 failed open (Overflow) 

Unit 3 failed open then Unit 2 failed closed 

Unit 3 failed open then Unit 2 failed closed then 

Unit 1 failed open (Dryout) 

Unit 3 failed open then Unit 2 failed closed then 
Unit 1 failed closed (Overflow) 



With the above definitions of states and the same definition of failure rates 



as given for Case A, the Markov equations are obtained and shown in Table 
5.8. Figure 5.5 shows the state transition diagram for these equations. 
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Table 5.8 

Equations for Tanlc Case F 



= -f 
dt [■ 



0 

dt 

dt 

dt 

dt 

dt 

dt 

dt 

dt 

dP, 



+ A2 + AgjPg 

[^2 ^ 3 ]^ 



fAi + A3IP2 + A^Pq 



5 ■ I 



A.Po 



= -AdPo + T A^P, 



‘'8 

dt 

dt 

dt 

dt 

dt 

dt 

dt 

dt 

dt 

dt 

dt 



8 



-\P 9 



3 2 
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= 0.5 AjPg 



A 1 P 9 
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Again the fourth order Runge-Kutta numerical integration program (from 
ref. P-A) was used to solve the equations and the time dependent results for 
the appropriate states were added together to produce the time dependent 
probability of tank failure due to overflow and due to dryout. The 
FLOW. UPDATE routine of the TANK program was modified to reflect the change 
in flow rate from unit three and then the program was run again using the 
same input file as for Case A to generate the simulation results. The input 
file is contained in Appendix D and an example output file is in Appendix E. 
The program was run for a simulated period of 1,000 hours and as in Case A, 
1,000 trials were used. Results of the simulation program are plotted in 
Figures 5.8 and 5.9 along with the Markov predictions for comparison. The 
results indicate reasonable agreement between the two methods. 

Also of note concerning the TANK simulation program is that from the 
test run to determine failures sequences, it was found that 13 of the 1,000 
trials involved failure of two units during the same continuous process 
integration time step. In other words, in the 1,000 trials, 13 times, the 
time separating successive failures was one hour or less. Thus approximately 
1.3 percent of the time the assumption made for the initiating event Markov 
analysis is not valid. 

Also of note for the simulation method is the computer time required 
to complete the problem. Using an integration time step of one hour, 
running the problem for a simulated time period of 1,000 hours, and 
performing 1,000 trials caused, the program to take two hours and fifty 
minutes for the Case A problem. Using the same parameter with the Case F 
problem, the test took four hours and forty- three minutes. The time for Case 
F was much longer because of the fact that in this case there were many more 



instances where the level of the tank oscillated about either the low or the 
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TANK PROBLEM 
CASE F - DRYOUT 




Figure 5.8 Case F - Cumulative Dryout Probability 
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TANK PROBLEM 
CASE F - OVERFLOW 




Figure 5.9 Case F - Cxamulative Overflow Probability 



I 

I 

i 




CUMULATIVE PROBABILITY 



Dynamic Simulation Model 



161 



TANK PROBLEM 
CASE A 




TIME(hours) 



Figure 5.10 Comparison With Aldemir's Results for Case A 



CUMULATIVE PROBABILITY 



Dynamic Simulation Model 



162 



TANK PROBLEM 
CASE F 




TIME(hours) 



Figure 5.11 Comparison With Aldemir's Results for Case P 
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high tank level set points. The time stated above is for runs on a COMPAQ 
386 personnel computer and times on an IBM XT are estimated to be about six 
times as long. Thus the time requirement for using this simulation method 
may be prohibitive. 

Although the problem solved in the simulation approach was slightly 
different than the one solved by Aldemir, results are compared in Figure 
5.11. It is seen that the simplified Markov model now has an observable 
error due to the assumptions made in its development. The simulation 
results, however still show reasonable agreement with Aldemir 's predictions 
using the dynamic Markov model. Note that the data plotted for Aldemir 's 
model are obtained from reference A- 5 and are corrected versions of the data 
presented in reference A-1. 

Certain improvements may be possible to improve the computer time 
required. One of these, is increasing the time of the integration time step 
used by the continuous process routine. Another is to more efficiently code 
the portions of the model which lead to oscillation of a component. Based 
on the difference in time required for Case A and Case F, this improvement 
alone may reduce solution time by 75% or more. Other techniques of 
optimizing the computer code may also certainly be possible as the code was 
written to be transparent, not necessarily efficient. It is evident that the 
continuous simulation routine is a valuable tool, however improvements can 
be made to increase the accuracy of results and to reduce the amount of 
computer time required. 

5 . 6 Chapter Summary 

In this chapter the use of continuous simulation methods was explored 
for use in analyzing the reliability of complex process control systems. The 
specific problem investigated was the tank level control problem addressed 
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by Aldemir in reference A-1. The simulation solution proposed was a modified 
version of the DYMCAM program discussed in previous chapters. This new 
program, called TANK, made use of the continuous capability available in the 
SIMSCRIPT II. 5 simulation language. 

The tank level control problem addressed by Aldemir was discussed in 
detail to provide insight into the exact nature of a simulation problem. The 
Case A and Case F scenarios were explored and all possible failure sequences 
were identified. An assumption was made concerning the time between failure 
events which allowed for an approximate solution to be developed against 
which the results of the simulation approach could be compared. 

In the third section of the chapter, the modifications made to create 
the TANK program were described. For the most part, the DYMCAM program was 
left intact with only minor changes being made to a few lines of the 
SIMSCRIPT code . Several routines were added to define the continuous 
variable to be used in the simulation. These new routines include a Tank 
process which models the fluid level as a continuous variable, and monitors 
the level to determine the control region the system is in, and based on this 
information, causes the opening and closing of control valves. This type of 
dynamic problem is not treated by most reliability analysis techniques. 

Once the program has been explained, the approximate Markov method is 
described in detail. The Markov states used for both Case A and Case F are 
listed in Tables 5.5 and 5.6 respectively and the Markov equations used are 
listed. These equations were solved using a fourth order Runge-Kutta 
numerical integration technique and the resulting time dependent system state 
information manipulated to provide a time dependent estimate of the 
probability of the tank failing by overflow or by dryout. 

The TANK simulation program was run for a simulated time period of 
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1,000 hours and for 1,000 Monte Carlo trials to provide the simulation 
estimate to the tank level control problem. These results were plotted with 
the results from the approximate Markov chain approach for comparison. It 
was seen that both methods give similar results for the probability of tank 
failure by overflow and dryout for both Case A and Case F. The results for 
Cases A and F also compare well with the results given by Aldemir in 
reference A- 5. 

The computer time requirements for running the simulation program on 
a personnel computer were quite large. This is due in large part to the 
presence of the oscillation of the fluid level about the upper or lower tank 
level set points. To reduce computer time requirements, it is possible to 
revise the code to reflect a more efficient program, and the integration time 
step can be increased. To increase the accuracy of the results, a larger 
number of trials must be performed. Since the time required is directly 
related to the number of trials performed, variance reduction techniques will 
certainly be necessary. The TANK program demonstrated the capability of 
using a continuous Monte Carlo simulation technique to solve complex process 
control system reliability analysis problems with satisfactory approximate 
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Chapter 6 

Sxunmary and Conclusions 
6.1 Discussion of Methods 

To evaluate the availability of a system there are two basic types of 
approaches. These are static and dynamic methods. Under the heading of 
static methods, the most well known technique is the fault tree. This method 
has seen extensive use in reliability analysis and is a valuable tool for 
calculating average system reliability. Another static method is the GO 
methodology. This is a computer method which uses inductive logic to achieve 
reliability analysis results. It's major advantage over the more widely used 
fault tree method is that it models individual system components and 
therefore provides a model which is easily reviewable and which can be 
modified easily to analyze slight variations on the original analysis 
problem. Both of these methods are good for determining average reliability 
information, but neither can be easily used to solve dynamic analysis 
problems . 

Many methods exist for solving dynamic system availability problems. 
One of the most commonly used is Markovian analysis. This method can provide 
exact analytical continuous -time descriptions of systems which can be modeled 
by a discrete state space. The major drawback of the technique , are the size 
of the state space when complex systems are to be considered, and that only 
exponentially distributed failure and repair time distributions can be used. 

A second dynamic analysis method is the event tree. This method 
provides modelling of the sequence of events which can lead to a designated 
outcome. The method provides an inductive means of calculating the 
reliability of a system where initiating faults can lead to unfavorable 
outcomes. The method does not explicitly model repair and failure cycles of 
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components and it can not be used to evaluate systems which have loops in 
system operation which may the analysis to return back to a previous node in 
the event tree a random number of times . 

Digraph techniques provide a means of handling systems with continuous 
process variables. The method is ideally suited to evaluating process 
control systems in which the state of components may depend on the value of 
a continuously varying signal. The results of a digraph analysis provide a 
listing of disturbances which can lead to undesirable performance of the 
system being analyzed. 

The GO-FLOW methodology is similar to GO, but it provides a dynamic 
capability. Thus this technique model provides an easily constructable 
reliability analysis model which can de used to evaluate dynamic systems. 
However, it can only be used to solve for discrete state systems, and is not 
directly useful in evaluating process control systems or any structure with 
continuously variable signals and component states. 

The most flexible method of availability analysis, is probably also the 
least used- This is the method of simulation. Monte Carlo simulation 
techniques provide a powerful alternative to solving complex system 
reliability analysis problems. In many cases, simulation can be used to 
solve problems to which there is no analytical solution. The method can be 
used to evaluate any type of phased mission problem. Since the model is 
frequently developed to fit only a particular problem or specific type of 
problem, often fewer assumptions or approximations are necessary and the 
model can be made to accurately reflect actual system behavior. 

Drawbacks of the Monte Carlo simulation method are that it only 
provides an estimate of the actual system reliability. The level of 
uncertainty in the prediction will be a result of the number of Monte Carlo 
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trials performed and the behavior of the random number generator employed. 
For better accuracy the number of trials can be increased, but this can lead 
to a large computer time requirement. Typically, an analytical solution 
method can produce results in a fraction of the time required for solution 
by simulation techniques, provided an analytic solution to the problem 
exists. However, significant time might also be involved in determining the 
form of the analytical solution for the system. 

In this work, a new Monte Carlo simulation model was developed for 
evaluating the dynamic availability of complex systems. The DYMCAM program 
is designed to be a general analysis tool with applicability to many types 
of engineering systems. The SIMSCRIPT II. 5 language provides the capability 
for all three major types of simulation approaches including event 
scheduling, process interaction, and continuous simulation, thus providing 
flexibility in program development. All three methods are used in the TANK 
program. 

The basic DYMCAM program is designed to provide a model which can 
analyze the time -dependent availability of dynamic systems, is easy to 
construct, and can be easily modified to incorporate additional features as 
needed. The program structure allows for prediction of time -dependent system 
unavailability information at any number of user specified time points 
throughout the course of the simulated time period, and it also provides time 
averaged unavailability information for the entire simulation time. It has 
the capability to schedule any number of external events thus providing a 
limitless phased mission capability. Five basic component types are 
presently modeled, however further components could easily be added if 
specific problem requirements call for increased modeling capabilities. Much 
like the GO and GO -FLOW codes in this respect, DYMCAM should be easy to 
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employ in system evaluation since it is expected that an input file can be 
written to evaluate a system using the DYMCAM code directly from a schematic 
of the system. 

The TANK code is a modified version of DYMCAM designed to demonstrate 
the capability for evaluating systems containing continuous variables. These 
systems, such as process control systems, can be quite difficult to evaluate 
using the analytical analysis tools available. The TANK code provides the 
ability to model a continuously variable tank fluid level and it also 
demonstrates how a simulation program can be used to model the occurrence of 
events not scheduled before the start of the simulation. The DYMCAM and TANK 
codes demonstrate that Monte Carlo computer simulation techniques can be 
employed to solve a wide variety of system availability analysis problems. 
6.2 Discussion of Results 

The DYMCAM program was first tested on two very basic component 
availability examples to demonstrate that the program does indeed provide 
meaningful results . The results obtained are accurate and the variance 
acceptable for the number of trials performed. The two examples consisted 
of a single component with exponentially distributed repair and failure 
distributions and a three state component possessing, in addition to these 
two states, an exponentially distributed repair delay state. In both cases 
the results agreed well with analytic predictions . 

The second case, involving the three state device, demonstrated a minor 
capability of the rather powerful DYMCAM subroutine called the 
Repair. Supervisor . This subroutine can be used to cause various types of 
repair delays and even to control which components are repaired and when. 
Repair resources can even be limited if this is necessary for analysis of 
certain systems. 
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The third example demonstrated solution of a simple two-out-of- three 
system. Success occurs if two of three parallel aligned pumps are operating 
and flow is being produced at the outlet valve which all three pumps supply 
pressure too. Results for this example again agreed well with Markov 
predictions for the system and further demonstrated the capability of the 
DYMCAM program to compute the availability of simple systems. The example 
also identified the desireable capability of having signal process strength 
incorporated into the model. Although not currently present, such 
capabilities could easily be added. 

The fourth test of the DYMCAM program demonstrated a simple phased 
mission problem. The example used was one taken from reference M-2 and has 
also been solved using the GO-FLOW methodology. Results obtained with the 
DYMCAM program indicated the simulation approach gives availability 
information equivalent to the values estimated by GO-FLOW. A sensitivity 
analysis was also performed on this problem to verify the hypothesis that the 
variance of results decreases with the increasing number of trials performed. 

The TANK program was designed to demonstrate the continuous capability 
of the SIMSCRIPT II. 5 simulation approach. Continuous variable modeling is 
an important aspect of simulation a simulation approach, since few analytical 
methods can treat such systems adequately. Aldemir proposes a discrete 
state-space continuous time solution method with probabilistic system 
behavior simulated by Markov chains in reference A-1. Also in this reference 
is the specific tank example process control problem addressed in this work. 

Using the TANK code, simulation solutions for the unavailability of the 
tank due to overflow and dryout were calculated for the Case A and Case F 
scenarios of reference A-1. Results compared favorably with Aldemir 's 
solutions, despite the fact that the component states treated in the TANK 
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model are somewhat different than the states assumed by Aldemir. A 
simplified Markov chain solution was also proposed in this work for 
comparison and the Markov results agreed within reasonable accuracy with the 
simulation results obtained for both Case A and F. For Case A, the 
simplified Markov solution provided results that agreed almost exactly with 
Aldemir' s solution, while for Case F the simulation results were in closer 
agreement with Aldemir' s solution than was the simplified Markov approach. 

The TANK program demonstrated that simulation of complex process 
control systems may provide a simple method of solution to a problem which 
is not readily solved by analytic methods. Results appear to be accurate, 
and the standard deviation of the results are related directly to the number 
of trials performed. 

Another important function demonstrated was the ease with which a 
simulation approach can change the state of components based on the state of 
a process variable or other components in the system, at any time point 
during a simulated run. This is an important function not easily handled by 
other reliability analysis techniques. By improving the DYMCAM program and 
properly exploiting this capability it will be possible to analyze many 
stochastic systems which were previously not easily quantifiable. 

6.3 Strengths and Weaknesses 

The DYMCAM dynamic simulation model demonstrated the capability of 
simulation programs to solve d3mamic reliability analysis problems. Values 
of unavailability can be calculated for a system at any time point during the 
simulation which the user chooses. In this respect, the program is equal in 
capability to continuous Markov analysis procedures. Although failure times 
are treated as exponentially distributed and repair times are Weibull 
distributed in the DYMCAM program, it is a simple matter to change the 
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program to use any type of transition distributions. 

DYMCAM can also be used to solve any manner of deterministic phased 
mission problem. Through use of external events, components and signals may 
be changed at will during the execution of the simulation. Although not 
incorporated into the basic DYMCAM code, the TANK code example demonstrated 
that it is even possible to simulate stochastic systems in which components 
are required to change operating state at time points determined by system 
operating characteristics. The TANK code also shows that Monte Carlo 
simulation can be successfully used to solve continuous variable reliability 
analysis problems such as process control systems. 

The major drawback of these simulation techniques are that they are 
only estimation tools and do not provide exact results as do analytical 
methods. The accuracy of the estimate improves with the nvimber of Monte 
Carlo trials performed, however the number of trials necessary to 
significantly reduce the variance of the estimate may be prohibitively large, 
requiring unacceptable amounts of computer time. As computers become faster, 
this may prove to be less of a problem, in which case, in theory, exact 
results can be obtained by using infinitely many trials, provided the 
simulation model of the system is an accurate one. 

It should be noted that the computer run times discussed in conjunction 
with the tests of this work should not be interpreted as meaning that 
simulation methods must always require excessive amounts of time. First, 
neither DYMCAM nor TANK were programmed for maximum efficiency, but rather 
to be as transparent as possible to the user. In addition, conversations 
with individuals from CACI indicate that the IBM/PC version of SIMSCRIPT II. 5 
does run very slowly. This is because the language was originally developed 
for mainframe computers, and the PC adaptation uses an interpreter, rather 
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than a compiler. SIMSCRIPT II . 5 will run much faster on a mini - computer . 

6.4 Conclusion and Recommendations 

It has been shown that Monte Carlo simulation methods provide a 
powerful tool for solving many types of complex system availability analysis 
problems. This work introduces a program which can be used to solve a wide 
variety of problems simply by entering an input file which accurately 
describes the relationships between components in the system. Many large 
complex systems have no adequate solution techniques, therefore advances in 
simulation technology is essential for solving many reliability analysis 
problems . 

As is evident from the variance of the results and computer time 
required to obtain them, many improvements in the method can be made. 
Cleaner coding of the program may improve run time requirements to some 
extent; however a more important area of concern should be in exploring 
methods of variance reduction. Incorporating such techniques may 
significantly reduce the need to use many Monte Carlo trials and can, 
therefore, reduce computer time requirements. Once run time has been 
significantly reduced, more extensive testing of the program should be done 
to better determine the limits of the simulation technique. 

The program should also be modified to consider the strength of process 
signals. Currently, signals are either on or off indicating only the 
presence of a process, not the actual strength. If signal strength 
capabilities were present then it would be an easy matter to determine, for 
instance, how many pumps were feeding water to a valve simply by the strength 
of the process signal from the valve. 

Another area for future work is on the Repair .Supervisor routine. This 
process could be expanded to provide limitless capabilities in managing 



Dynamic Simulation Model 



174 



repair resources available to a system. This routine could be used to 
control the order and scheduled times of repair for individual components 
based on any desireable scheduling scheme. 

The DYMCAM dynamic simulation model demonstrates the basic capability 
of Monte Carlo techniques to solve any manner of complex system reliability 
analysis problems. In the future, as analysis of advanced engineering 
systems is required, development and application of approaches such as this 
will become desireable and even necessary since analytic techniques may not 
be practical or possible. Future improvements of the DYMCAM program should 
make it a valuable tool for computing availability of dynamic systems. 



Dynamic Simulation Model 



175 



References 



A-1 T. Aldemir, "Computer-Assisted Markov Failure Modeling of Process 

Control Systems," IEEE Transactions on Reliability . Vol. R-36, No. 1, 
(April 1987). 

A- 2 T. Aldemir, "Quantifying Setpoint Drift Effects in the Failure Analysis 

of Process Control Systems," Reliability Engineering &. System Safety . 
Vol. 24, No. 1, (1989). 

A-3 R. N. Allan, Y. A. Jebril, A. Saboury, and J. Roman, "Monte Carlo 

Simulation Applied to Power System Reliability Evaluation," in System 
Simulation (10th Advances in Reliability Technology Symposium) Elsevier 
Applied Science Publishing Company, Inc., New York, 1988. 

A-4 G. E. Apostolakis, S. L. Salem, and J. S. Wu, "CAT; A Computer Code for 
the Automated Construction of Fault Trees," NP-705 Electric Power 
Research Institute, (1978). 

A-5 T. Aldemir, personal communication to N. Siu, Massachusetts Institute 
of Technology, April 10, 1989. 

B-1 R. Billinton and M. Patwardhan, "A Modified GO Methodology for System 
Availability Assessment," in Poster Session (10th Advances in 
Reliability Technology Symposium) Elsevier Applied Science Publishing 
Company, Inc., New York, 1988. 

B-2 R. Billinton and R. N. Allan, Reliability Evaluation of Engineering 
Systems: Concepts and Techniques . Plenum Press, New York, 1983. 

B-3 A. Bendell, "New Methods in Reliability Analysis," in Reliability 

Technology: Theory and Applications (European Reliability Conference 
1986; Copenhagen, Denmark) Elsevier Science Publishing Company, Inc., 
New York, 1986. 

B-4 J. Banks and J. S. Carson II, Discrete -Event System Simulation . 
Prentice-Hall, Inc,, Englewood Cliffs, New Jersey, 1984. 

B-5 J. Banks and J. S. Carson II, "Process- interaction Simulation 
Languages," Simulation . Vol. 44, No. 5, (May 1985). 

C-1 CACI, SIMSCRIPT II. 5 Programming Language . CACI , Inc . -Federal , Los 
Angeles, 1987. 

C-2 CACI, PC SIMSCRIPT II ,5 Introduction and User's Manual . Third Edition, 
CACI, Inc . -Federal , Los Angeles, 1987, 

D-1 B, S. Dhillon, Systems Reliability. Maintainability and Management . 
Petrocelli Books, Inc., New York, 1983. 

D-2 B. S. Dhillon and S. N. Rayapati, "A Complex System Reliability 

Evaluation Method," Reliability Engineering . Vol. 16, No. 2, (1986), 



Dynamic Simulation Model 



176 



F-1 A. M. Fayek, Introduction to Combined Discrete -Continuous Simulation 
Using PC SIMSCRIPT II. 5 . CACI, Inc . -Federal , Los Angeles, 1988. 

G-1 W. V. Gately and R. L. Williams, "GO Methodology - Overview," NP-765 
Electric Power Research Institute, (1978). 

G-2 J. N. P. Gray, "Continuous -Time Markov Methods in Solution of Practical 
Reliability Problems." Reliability Engineering . Vol. 11, No. 4, (1985). 

G-3 R. Ghajar and R. Billinton, "A Monte Carlo Simulation Model for the 

Adequacy Evaluation of Generating Systems , " Reliability Engineering 6e 
System Safety . Vol. 20, No. 3, (1988). 

J-1 L. E. Johnson, "Dynamic and Steady-State Solutions for a General 

Availability Model," IEEE Transactions on Reliability . Vol. R-34, No. 
5, (December 1985). 

J-2 K. S. Jeong, S. H. Chang, and T. W. Kim, "Development of the Dynamic 
Fault Tree Using Markovian Process and Super Component,” Reliability 
Engineering, Vol. 19, No. 2 (1987). 

K-1 T. Kohda and E. J. Henley, "On Digraphs, Fault Trees, and Cut Sets," 
Reliability Engineering & System Safety . Vol. 20, No. 1, (1988). 

K-2 H. Kumamoto, T. Tanaka, and K. Inoue, "A New Monte Carlo Method for 
Evaluating System- Failure Probability," IEEE Transactions on 
Reli a b ilit y, Vol. R-36, No. 1, (April 1987). 

L-1 N. Limnios, "A Note on the Computation of Markovian Systems,” 

Reliability Engineering & System Safety . Vol. 23, No. 3, (1988). 

L-2 E. E. Lewis and T. Zhuguo, "Monte Carlo Reliability Modeling by 

Inhomogeneous Markov Processes," Reliability Engineering . Vol. 16, No. 
4, (1986). 

L-3 M. 0. Locks, "Recent Developments in Computing of System-Reliability," 
IEEE Transactions on Reliability . Vol. R-34, No. 5, (December 1985). 

L-4 A. M. Law and C. S. Laraey, An Introduction to Simulation Using 
SIMSCRIPT II .5 . CACI, Inc . -Federal , Los Angeles, 1984. 

M-1 N. J. McCormick, Reliability and Risk Analysis . Academic Press, Inc., 
Orlando, Florida, 1981. 

M-2 T. Matsuoka and M. Kobayashi , "GO-FLOW: A New Reliability Analysis 

Methodology," Nuclear Science and Engineering . Vol. 98, No. 1, (January 
1988) . 

M-3 T. Matsuoka and M. Kobayashi, "The GO -FLOW Methodology: A Reliability 
Analysis of the Emergency Core Cooling System of a Marine Reactor Under 
Accident Conditions,” Nuclear Technology . Vol. 84, No. 3, (March 1989). 



Dynamic Simulation Model 



177 



0-1 R. M. O'Keefe, "The Three-phase Approach: A Comment on 'Strategy- 
related Characteristics of Discrete -event Languages and Models'," 
Simulation . Vol. 47, No, 5, (November 1986). 

P-1 A. Pages and M. Gondran, System Reliability - Evaluation and Prediction 
in Engineering . North Oxford Academic Publishers Ltd., 1986. 

P-2 D. B. Parkinson, "Fast Availability Simulation," Reliability 
Engineering . Vol. 18, No. 3, (1987). 

P-3 I. A. Papazoglou and E. P. Gyf topoulos , "Markovian Reliability Analysis 
Under Uncertainty with an Application on the Shutdown System of the 
Clinch River Breeder Reactor," NUREG /CR-0405, September 1978. 

P-4 W. H, Press, B. P. Flannery, S. A. Teukolsky, and W. T, Vetterling, 
Numerical Recipes . Cambridge University Press, New York, 1986. 

R-1 E. C. Russell, Building Simulation Models with SIMSCRIPT II. 5 . CACI , 
Inc . -Federal , Los Angeles, 1983. 

S-1 J. W. Schmidt and R. E, Taylor, Simulation and Analysis of Industrial 
Systems . Irwin, Homewood, Illinois, 1970. 

S-2 A. F. Seila, "SIMTOOLS: A Software Tool Kit for Discrete Event 

Simulation in Pascal," Simulation . Vol. 50, No. 3, (March 1988). 

W-1 WASH 1400, "An Assessment of Accident Risks in U.S. Commercial Nuclear 
Power Plants," Reactor Safety Study, WASH 1400, U.S.A.E.C., 1974. 



Dynamic SimulaCion Model 



178 



Appendix A 

DYMCAM Input File Description 

Figure A.l shows an example listing of an input file for the DYMCAM 
program. Line nimabers are indicated to aid in describing the setup of an 
input file for a specific program, since different problems will require 
different mambers of input data file lines. This discussion should provide 
all information necessary to create a file to solve any specific problem for 
the desired system unavailability information. Any text editor can be used 
to create the input file, and the file can be given any name acceptable by 
DOS requirements. 

Line 1 is the title line and can be up to 80 characters long. If the 
title is less than 80 characters long, it will be necessary to enter spaces 
to extend the line to the full length. The read statements in the Input 
routine are formatted reads, and therefore, if 80 characters are not found 
on the first line, the program will look on the next line for the remaining 
characters of the title , thus misreading the desired input data contained in 
later lines. Some text editors, such as K-EDIT, do not save the trailing 
blank spaces and thus could cause a problem if attempts are made to use them 
to create input files. One trick that can be used if the title is short, is 
simply to enter spaces out to colvunn 80 of line 1, and then enter a character 
in column 81. K-EDIT will save the entire line, but DYMCAM will only read 
the first characters of the line, thus printing only the title which was 
desired. 

Line 2 contains the number of simulated hours for which the program is 
to be run. The format is d(10,2) which means the program is looking for a 
decimal number with two digits after the decimal point, and that the number 
will be found in the first ten columns of line 2. For this particular 
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LINE NUMBER 


INFORMATION 




1 


Test Simulation Program 




2 


1000.00 




3 


0 




4 


1000 




5 


11 




6 


0 




7 


0.00 




8 


100.00 




9 


200.00 




10 


300.00 




11 


400.00 




12 


500.00 




13 


600.00 




14 


700.00 




15 


800.00 




16 


900.00 




17 


1000.00 




18 


2 




19 


BATTERY passive operating 


1 


20 


0.1 0.0 




21 


1.0 1.0 0.0 




22 


system process 


0 


23 


SWITCH process 


1 


24 


SWITCH switch open 


3 


25 


0.3 0.0 




26 


1.0 1.0 0.0 




27 


system command 


0 


28 


system power 


1 


29 


BATTERY process 


0 


30 


system process 


0 


31 


standby 




32 


1 




33 


3 




34 


100.00 0 




35 


1 




36 


system BATTERY process 




37 


1 




38 


500.00 0 




39 


1 




40 


system SWITCH command 




41 


-1 




42 


900.00 1 




43 


SWITCH 




44 


open 




45 


0 





1 



1 



Figure A.l 

Exeunple DYMCAM Input File 



Dynamic Simulation Model 



180 



format specification it is not necessary to have the value right justified 
in the ten column field of interest. The value can be entered left 
justified, if desired, and the program will read all digits to the left of 
the decimal point as an integer value and then read the next two digits 
following the decimal and ignore any other characters which may be in the 
first ten coltimns . It is critical only that the decimal appear somewhere in 
the first 10 columns so that format specifications are satisfied. If the 
decimal appears in columns 9 or 10, then the one or two digits following the 
decimal for which values have not been assigned, will be recorded as being 
zero. This is true for any number read with a d(x,y) format. Regardless of 
the value of y, as long as a decimal is somewhere in the x colijmns specified, 
then y characters will be assigned following the decimal. If y characters 
are present in the input field, then they will be entered, if not, then 
zeroes will be entered for the remaining digits. For the example shown, the 
input value of simulation time is 1000 hours. 

Line 3 is an integer value as must be entered in column 10. The value 
which may be entered is either a 0 or a 1. The 0 entry signifies that the 
run is to be a normal run. The 1 entry indicates that the run will be a test 
run to see if proper program operation is occurring. Entering a 1 will cause 
all components to fail at their mean failure time (one over the failure rate) 
and all repairs to occur at their mean repair time. Thus by entering a 1, 
it is possible to check and make sure that all components are failing and 
being repaired as expected. The example shown in Figure A.l has a 0 entered 
indicating the run will be a normal run. 

Line 4 indicates the nximber of Monte Carlo trials to be performed. The 
nximber is entered as an integer value and must be right justified so that the 
right most character of the number is entered in column 10 of line 4. THe 
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example shows a value of 1000 indicating that 1000 Monte Carlo trials are to 
be performed. 

Line 5 specifies the number of time points for which dynamic system 
unavailability data is required. This number is also an integer value and 
must also be right justified with the one's digit falling in column 10. 
There is no requirement as to the number of time points to be entered. If 
desired, a zero can be entered and no dynamic information will be calculated 
for the system. For the example problem, 11 time points will be used for the 
dynamic unavailability analysis. 

Line 6 is an integer value referring to the type of time distribution 
desired for the dynamic unavailability analysis. The integer number 0, 1, 
or 2 must be entered in column 10 of line 6. Entering a 0 indicates that the 
next lines of the input file will contain the desired time points. For the 
example of Figure A.l, a value of 0 is specified, indicating that the next 
11 (number of time points specified in line 5) lines of the input line will 
contain the time points of interest. If a 1 had been entered, then the 11 
time points would have been chosen as uniformly distributed between time zero 
and the value specified in line 2. The program automatically chooses zero 
and the value of line 2 as two of its time points, thus the remaining 9 
points for this example would be chosen uniformly distributed between the 
beginning and end times. For this case, the points chosen would be the same 
ones entered in lines 7 through 17, therefore this program feature allows for 
simplification of the input file. 

If a value of 2 is entered in column 10 of line 6, then the program 
will choose values for the time points which are log distributed between the 
zero time and the end of simulation time specified in line 2. As was the 
case with entering a 1, the time zero point and the end of simulation time 
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are automatically chosen. The remaining N - 2 points are calculated by 
taking the log of the line 2 value, dividing it by one less than the value 
of line 5, and then taking the inverse log of integer multiples of this 
result, for time points between the two end times of the distribution. This 
feature may be useful for evaluating the unavailability of a system which is 
suspected of having an exponentially distributed result. Since the time 
required to run the simulation program is directly related to the nxamber of 
time the program is interrupted to take another time dependent unavailability 
sample, it is desireable to keep the number of time points specified in the 
input file to a minimum, while still providing sufficient data to properly 
evaluate the dynamic behavior of the system. 

Line 18 of the input file specifies the number of components contained 
in the system. For the example the number of components is 2. This value 
will always be an integer value and must be entered right justified with the 
right most digit falling in column 10. For every component indicated by this 
number, there will be a minimvim of five line of data in the input file. For 
the example of Figure A.l, the first component is described in lines 19 
through 23 and the second component is described in lines 24 through 30, 

Each component must have a first line entered in the format of lines 
19 and 24. The first 10 colximns are reserved for the components name. The 
name can contain any characters desired, but must not contain spaces. It 
need not be left or right justified. It need only be less than or equal to 
10 characters in length. The SIMSCRIPT language distinguishes between small 
and capital letters, therefor it is important that if capital letters are 
used for component names, that this is done consistently every where a 
specific component name is mentioned. All other text, other than component 
names, must be entered in lower case letters, since this is what the DYMCAM 















f -4m 




1 














'“S 









^ 

-t. ‘•'■■y^'^l^l 




Dynamic SimulaCion Model 



183 



program has been programed to recognize. 

Columns 11 through 20 for the first line of each component must contain 
the component type designation. This, as all text, need not be justified, 
but must be in lower case letters. Columns 21 through 30 should contain the 
components initial state upon execution of the simulation. This information 
must also be in lower case letters. Also on this line, the number of input 
and output signals used by the component should be specified. Any number of 
input and output signals can be assigned to a given component, however, for 
all components, at least one input and one output signal must exist. The 
number of inputs is an integer value and must be right justified in the 
colxomn 31 to 35 field, while the number of output signals must be entered as 
an integer value right justified in the 36 to 40 column field. Line 19 of 
the example refers to a passive element named BATTERY which is initially in 
standby at time zero and has one input and one output signal. Line 24 
indicates a switch named SWITCH which is initially open and has three inputs 
and one output signal. 

The second line of each component data field (lines 20 and 25 of the 
example) contains the failure data for the component. The first 10 columns 
contain the demand failure probability. The format for reading this value 
is d(10,5). As discussed earlier, this means that the data will be contained 
in a field 10 columns wide, and may include five digits following the 
decimal. If more than five digits are entered after the decimal, they will 
be ignored. The second data field of this line is from column 11 to column 
20. This will contain the failure rate, lambda, for the component. The 
format for this value is also d(10,5). As stated above, neither of these 
values need be justified in their data fields. It is only critical that a 
decimal point be entered somewhere in the field. Line 20 of Figure A.l, for 
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example, indicates a value of 0.1 for the BATTERY demand failure probability. 
This value was entered with only one decimal place, since only one decimal 
was needed, regardless of the fact that the format specified five decimal 
places can be entered. Likewise for the SWITCH in line 25, and the failure 
rates for both components . 

The third line for each component (lines 21 and 26) must contain the 
repair information. Three data values are entered and each is read in the 
d(10,5) format. The first value is the alpha parameter for the Weibull 
distribution and it must be found in columns 1 through 10. The second value 
is the beta parameter for the Weibull repair distribution and must be entered 
in columns 11 through. The third value is the probability the component is 
repairable once it has failed. This number is entered in columns 21 through 
30. If exponentially distributed repair is to be considered, this can be 
accomplished by entering a 0 for the value of alpha, and treating beta as 
being equal to the mean repair time for the component (one over mu, the 
exponential repair rate) . For cases when a 1 is entered in line 3 of the 
input file, the mean time to repair is treated as being equal to the Weibull 
parameter, beta, regardless of the value of he alpha parameter. For the 
example shown, repair is not considered, thus the values entered in lines 21 
and 26 do not have physical significance, except for the zeros, which simply 
indicate that once the component fails, it stays failed since it is not 
repairable . 

For every signal in the system, a line like lines 22, 23, and 27 
through 30 must be specified. Since signals must be associated with the 
components they link, they will always be listed following the component. 
The number of signals described following any component will equal the s\im 
of the number of input and output signals specified for the given component. 
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For the example shown, the BATTERY has one input and one output, thus two 
signals are specified. For the SWITCH, there are three inputs and one 
output, thus four signals are specified. The input signals for a component 
must always be specified first and the output components last. The order of 
specifying several input or output files for a given component, however, is 
not important as long as the above rule is obeyed. Every signal which does 
not originate from, or terminate at the system level, must be contained in 
two component listings. This is clearly evident because each signal must 
have an origin and a destination. Thus if it does not come from or go to the 
system, it must travel between two components of the system. 

Information concerning signals must always begin in the column 11 to 
20 field. The first 10 columns to provide ease in viewing the file. The 
first field of the description (columns 11 to 20) attaches the signal to 
another component. For input signals, this field contains the name of where 
the signal came from (either the system or an other component) , and for 
output signals the data field contains the destination of the signal (either 
the system or an other component) . Thus each signal is tied between two 
components . 

The second data field for each component is contained in columns 21 
through 30 and indicates the type of signal (either command, power, or 
process). As with all text data fields, the data need not be justified. The 
third piece of data concerning each signal, is it's strength at the start of 
the simulation. For power and process signals the strength is 0 if power is 
not available or the process variable is not present, and the strength is 1 
if power is available or the process variable exists. For command signals, 
a value of 0 indicates no command, while a value of 1 indicates to open the 
switch or valve (or start the active component). A value of -1 indicates to 
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close the valve or switch (or to stop the active component) . These values 
are entered as integers and are right justified in column 35. For the 
example of Figure A.l, the BATTERY has one input and one output signal. The 
input is a process signal coming from the system and is initially off, while 
the output signal is a process signal going to the SWITCH and is also 
initially off. The SWITCH has three inputs and one output. Two of the 
inputs are from the system and reflect the power and command signals to the 
SWITCH. Initially the switch has power but no command signal. The other 
input to the switch is the process signal which comes from the BATTERY. The 
output signal is aa process signal which goes to the system. 

Line 31 provides information about the initial state of the system. 
The program does not calculate the system state until a time 0+ which is 
slightly greater than time zero, thus to artificially set the system to its 
desired initial operating state it is necessary to set it at the beginning 
of the rum. For the system to be available at time zero, the system status 
is set to operating or standby. Thus the value entered for initial system 
state is either operating, standby, or failed. This data is entered in the 
first 10 columns of the input file line. Line 31 of the example indicates 
the system initially starts in the standby condition. 

The next required line in the input file is the system success 
criteria. This is the number of output signals directed to the system which 
must be on in order for the system to be considered available. It is entered 
as an integer value and must be right justified in column 10 of the data 
line. For the example, the value entered in line 32 is one, specifying that 
at least one output signal to the system must be on in order for the system 
to be available. For this example, there is only one output signal to the 
system, the output process signal from the switch, thus the system is only 
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available if the switch is closed and an output process signal is being 
generated, i.e. the BATTERY must also be operating. 

Next, the number of external events to be included in the problem 
scenario must be entered. This value will be an integer and is read right 
justified from column 10 of the data file line. This value may be zero if 
the problem to be analyzed is not a phased mission one, and if this is the 
case, this will be the last line of the input file. For the example of 
Figure A.l, line 33 indicates that there are 3 external events for this 
problem. 

For each external event, at least four lines of data must be entered. 
The first line contains the time at which the event is scheduled to occur. 
This information is contained in columns 1 to 10 and is read in the d(10,2) 
format. Following this, in coliomns 11 to 20, the number of components 
effected by the external event are given. This is an integer value and must 
be entered right justified in column 20. Every external event must affect 
at least one component or signal, but not necessarily both, therefor this 
value may often be 0 as it is in lines 34 and 38 of the example. If the 
value is 1 or greater, then the next lines will list the components effected 
by the external event. Each line, like line 43 of the example, simply lists 
the name of the affected component. The name must be found in the first 10 
coliimns of the data file line. For the example, the external event changes 
the state of the SWITCH. The program is written such that all components 
changed by a given external event, are affected in the same manner. Thus the 
next data file line following the component names, gives the new state of 
these components. For the example, the external event opens the SWITCH at 
900.00 hours into the simulation. Thus line 44 contains the instruction to 
open. This component change of state must be entered in the first 10 coliomns 
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of the data line. 

The next line of an external event specifies the number of signals 
affected by the event. This will be an integer value and must be entered 
right justified in column 10 of the data line. For the example of Figure 
A.l, the third external event does not change any signals as is indicated by 
the 0 in line 45. The first to external events change one signal each. This 
is indicated in lines 35 and 39 of the example input file. If a signal is 
changed, then two lines must be entered for each signal changed by the 
external event. The first line contains the origin of the signal, the 
destination of the signal, and the type of signal. These three data entries 
are text information and are entered in colxomns 1 to 10, 11 to 20, and 21 to 
30 respectively. The next input data line contains the new strength of the 
signal. This will be an integer value and is entered right justified in 
column 10 of the data file line. For the example of Figure A.l, the first 
external event changes the process signal from the system to the BATTERY 
(line 36) . The new strength (line 37) specifies that the signal is to be 
turned on so that the BATTERY may now supply current. The second external 
event of the example effects the command signal from the system to the 
SWITCH. It causes the command signal to change to -1 at the 500.00 hour time 
point which will cause the switch to close, provided it does not experience 
a demand failure. Line 40 of the example specifies the signal, while line 
41 gives the new value. 

With the current program structure, it is possible to change many 
signals with a single external event, and to change each to a different 
signal strength. These same signals may be changed again at a later time in 
the simulation by another external event. Components, on the other hand, can 
only be changed once by an external event. This means that if an external 
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event is used at the 500.00 hour time point to open a switch, the same switch 
can not be closed with an external event at a later time in the simulation 
(although it may have its input command signal changed) . This is because of 
the way external events were treated in development of this basic 
demonstration program. It would be possible to modify the program to allow 
multiple state changes of a given component, if such a capability were 
desireable . 

Also with the current structure, all components changed by a given 
external event must be changed to the same new state. This is not such a 
problem since any number of external events can be scheduled to occur at 
exactly the same time. In fact, the motivating idea for the external event 
was that each event would effect only a single component or type of 
component. If it is desireable, the External Event routine could certainly 
be modified to allow multiple component changes during a single external 
event . 

This appendix should supply all the information necessary for writing 
input files for the DYMCAM program. Care must be taken to ensure that all 
information is properly formatted. For further examples of input files. 
Appendix D can be consulted which contains several input files used for the 
various test runs performed in chapters four and five. Also note in Appendix 
D that all data file lines (with the exception of the title line) contain 
data only up through column 40. Since SIMSCRIPT will not look beyond this 
point for any data, it is possible to use this "blank space" to include 
comments concerning the input file data for future reference and ease of 
understanding. This has been done for all test cases run. 
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Appendix B 

DYMCAM Program Listing 
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1 preamble 

2 " 

3 ' ' RISK - Test program to simulate system behavior 

4 " 

5 " 03/28/89 

6 " 

7 permanent entities 

8 



9 every component . record 

10 has a component_name, 

11 a component_type , 

12 a number_inputs, 

13 a number_outputs, 

14 a response_function, 

15 an initial_state, 

16 a demand_failure_frequency, 

17 a run_failure_frequency, 

18 a repair_probability, 

19 a repair_function_shape, and 

20 a repair_function_scale 

21 

22 every external. event. record 

23 has an occurrence_time, 

24 a number_components, 

25 a new_state, 

26 a number_signals, and 

27 a new_strength 

28 

29 define response_function as a subprogram variable 

30 define component_name , component_type , initial_state, 

31 and new_state as text variables 

32 define demand_failure_frequency, run_failure_frequency, 

33 repair_probability, repair_function_shape , 

34 and repair_function_scale as real variables 

35 define number_inputs, number_outputs, number_components, 

36 number signals, and new strength as integer variables 

37 " 

38 " 2-d arrays associated with permanent entities. 

39 " 

40 define input. name, output. name, input. signal. type, 

41 output. signal. type, extevnt. component, extevnt. origin, 

42 extevnt. destination, and extevnt . stype 

43 as 2-dimensional text arrays 

44 define input. signal. strength and output . signal . strength 

45 as 2-dimensional integer arrays 

46 define test as a 1-dimensional text array 

47 define signal . status as a 1-dimensional integer array 

48 

49 processes include call. update, schedule. avail. samples, 

50 schedule. external. events, repair. supervisor, 

51 stop. tank, and stop. scenario 

52 

53 every component 

54 has a name, 

55 a component. type. 



' 'TANK 



56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

104 

105 

106 

107 

108 

109 
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a response. function, 
an old. state, 
a state, 

a demand. failure. frequency, 
a run. failure. frequency, 
a repair. probability, 
a repair. function. shape, 
a repair. function. scale, 
a failure. time, 
a status, 

and owns an input. sset and 
an output. sset 

and may belong to a system. cset. 



a tank. input. cset, ''TANK 

a tank. output. cset, "TANK 

and an extevnt.cset 

every tank ' 'TANK 

has a high. level, "TANK 

a low. level, "TANK 

a high. set, "TANK 

a low. set, "TANK 

a level, "TANK 

a flow. rate, in, "TANK 

a flow. rate. out, "TANK 

a net. flow. rate, "TANK 

and owns a tank. input. cset, ''TANK 

a tank. output. cset, "TANK 

a tank, input. sset, and "TANK 

a tank. output. sset "TANK 

and belongs to a system. tset "TANK 



every external . event 

has an occurrence. time, 
a new. state, 
a number. signals, 
a signal. origin, 
a signal. destination, 
a signal. typee, and 
a new. strength 
and owns an extevnt.cset 
and belongs to a system. eset 

every availability 

has a time. avail, and 
a time. avail. data 

define time_avail as a 1-dimensional real array 
define time. avail and time. avail. data as real variables 
define tank. condition as an integer function ''TANK 

define response. function as a subprogram variable 
define name, component. type, old. state, state, new. state, 
signal. origin, signal. destination, and signal. typee 
as text variables 

define demand. failure. frequency, run. failure. frequency , 
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111 repair. probability , repair. function. shape, 

112 repair. function. scale, failure. time, occurrence. time, 

113 high. level, low. level, high. set, low. set, 

114 flow. rate. in, flow. rate. out, net. flow. rate, 

115 and number. signals as real variables 

116 define status and new. strength as integer variables 

117 define level as a continuous double variable 

118 " 

119 " Later versions may define signals as processes (so time delays 

120 " can be built in). 

121 " 

122 temporary entities 

123 

124 every signal 

125 has a signal. type, 

126 an origin, 

127 a destination, 

128 an old. strength, and 

129 a strength 

130 and may belong to an output. sset, 

131 an input. sset, 

132 a tank. input. sset, 

133 a tank. output. sset, 

134 a system. boundary. sset, 

135 a system. success. sset, and 

136 a system. sset 

137 

138 define cptr, sptr, eptr, aptr, and tptr 

139 as 1-dimensional pointer arrays 

140 

141 define signal. type, origin, and destination as text variables 

142 define old. strength and strength as integer variables 

143 ' ' 

144 " System characteristics. 

145 " 

146 the system owns a system. boundary. sset, 

147 a system. success. sset, 

148 a system. cset, 

149 a system. sset, 

150 a system. eset, and 

151 a system. t'set "TANK 

152 

153 define failure. translation as a text function 

154 define job. title, initial. system. state, and system. state 

155 as text variables 

156 define system. ind.var and simulation. time as real variables 

157 define ntrial, system. success . criterion, ntimes, 

158 distribution. type, run. type, and total. signal. count 

159 as integer variables 

160 define unavailability. dist as a 1-dimensional real array 

161 define trial. unavail as a real variable 

162 

163 accumulate trial . availability as the mean of system. ind.var 

164 tally average. unavailability as the mean, 

165 variance. unavailability as the variance. 



' 'TANK 
' 'TANK 



' 'TANK 



' 'TANK 
' 'TANK 

' ' TANK 
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define 

define 

define 

define 



166 

167 

168 

169 

170 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 

181 end "preamble 



maximum. unavailability as the maximum, 

and minimum. unavailability as the minimum of 

trial. unavail 



off to mean 0 
on to mean 1 
no to mean 0 
yes to mean 1 
define .working to mean 1 
define .resetting to mean 2 
define . awaiting. repair to mean 3 
define .under. repair to mean 4 
define .not. repairable to mean 5 
define .reset. run to mean 6 



) 




3 
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1 main 

2 define trial as an integer variable 

3 " 

4 ' ' Problem input 

5 " 

6 call input 

7 call run. initialize 

8 call tank. initialize. run "TANK 

9 add .003 to simulation. time 

10 for trial = 1 to ntrial 

11 do 

12 call trial. initialize 

13 call tank. initialize. trial "TANK 

14 activate a call. update now 

15 activate a schedule. avail. samples now 

16 activate a schedule. external. events now 

17 activate a stop. tank in simulation. time hours "TANK 

18 activate a stop. scenario in simulation. time hours 

19 start simulation 

20 let unavailability. dist(trial) = 1 - trial .availability 

21 let trial. unavail = trial. availability "TANK 

22 let time.v = 0 

23 reset totals of system. ind.var 

24 loop 

25 

26 call run. output 

27 

28 end ''main 
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1 routine active given component 

2 " 

3 ' ' Develops output signals for an active component 

4 " using explicit command signals. Assumes that the component 

5 " has one or more command signal inputs, power inputs, and 

6 " process inputs: 

7 ' ' 



8 " 
9 " 
10 " 
11 " 
12 " 

13 " 

14 " 

15 " 


input command 

input power 

input process 

Condensed decision tabli 

Command Power 

Case Input Input 


Process 

Input 


output 

Initial 

State 


process 

Final Process 

State Output 


17 " 


1 


- 


- 


- 


failed 


failed 


no 


18 " 


2 


- 


no 


- 


standby 


standby 


no 


19 " 


3 


stop 


yes 


- 


standby 


standby 


no 


20 " 


4 


none 


yes 


- 


standby 


standby 


no 


21 " 


5 


start 


yes 


no 


standby 


standby* 


no 


22 " 












failed 


no 


23 " 


6 


start 


yes 


yes 


standby 


standby* 


no 


24 " 












operating 


yes 


25 


7 


- 


no 


- 


operating 


standby 


no 


26 " 


8 


stop 


yes 


no 


operating 


failed 


no 


27 " 












standby 


no 


28 " 


9 


stop 


yes 


yes 


operating 


operating* 


yes 


29 " 












standby 


no 


30 " 


10 


none 


yes 


no 


operating 


failed 


no 


31 " 


11 


none 


yes 


yes 


operating 


operating 


yes 


32 " 


12 


start 


yes 


no 


operating 


failed 


no 


33 " 


13 


start 


yes 


yes 


operating 


operating 


yes 


34 " 


14 


- 


- 


- 


standby* 


standby* 


no 


35 " 


15 


- 


no 


- 


operating* operating* 


no 


36 " 


16 


- 


yes 


no 


operating^ 


► failed 


no 


37 " 


17 


- 


yes 


yes 


operating* operating* 


yes 


38 " 

















39 define rule as a saved 2-dimensional text array 

40 define component as a pointer variable 

41 define index. command, total .command, number. power, total. power, 

42 number. process, total. process, output. strength, ruletype, 

43 success, and j as integer variables 

44 define later. case as a saved Integer variable 

45 " 

46 '' Enter decision table. 

47 " 

48 if later. case eg .no 

49 reserve rule as 17 by 4 



50 


let 


rule (1, 1) 


- 


II II 


let 


rule(l,2) 


= 


II II 


51 


let 


rule (1, 3) 


= 


nil 


let 


rule (1,4) 


= 


"failed" 


52 


let 


rule(2,l) 


= 


II II 


let 


rule(2,2) 




"no" 


53 


let 


rule(2,3) 


= 


II II 


let 


rule (2, 4) 


= 


"standby* 


54 


let 


rule(3,l) 


= 


"stop” 


let 


rule (3, 2) 


= 


"yes" 


55 


let 


rule(3,3) 


= 


II II 


let 


rule(3,4) 


= 


"standby* 
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56 


let 


rule (4,1) =« 


"none" 


let 


rule(4,2) = 


•lyes" 


57 


let 


rule(4,3) = 


II II 


let 


rule (4, 4) = 


"standby" 


58 


let 


rule(5,l) = 


"start" 


let 


rule(5,2) = 


"yes" 


59 


let 


rule(5,3) = 


"no" 


let 


rule(5,4) = 


"standby" 


60 


let 


rule(6,l) = 


"start" 


let 


rule(6,2) = 


"yes" 


61 


let 


rule(6,3) = 


"yes" 


let 


rule(6,4) = 


"standby" 


62 


let 


rule(7,l) = 


II II 


let 


rule(7,2) = 


"no" 


63 


let 


rule(7,3) = 


II H 


let 


rule (7, 4) = 


"operating" 


64 


let 


rule(8,l) = 


"stop" 


let 


rule(8,2) = 


"yes" 


65 


let 


rule(8,3) = 


"no" 


let 


rule(8,4) = 


"operating" 


66 


let 


rule(9,l) = 


"stop" 


let 


rule(9,2) = 


"yes" 


67 


let 


rule(9,3) =• 


"yes" 


let 


rule(9,4) = 


i "operating" 


68 


let 


rule(10,l) 


= "none" 


let rule(10,2) 


= "yes" 


69 


let 


rule(10,3) 


= "no" 


let 


rule(10,4) 


= "operating" 


70 


let 


rule(ll,l) 


= "none" 


let 


rule(ll,2) 


= "yes" 


71 


let 


rule(ll,3) 


- "yes" 


let 


rule(ll,4) 


= "operating" 


72 


let 


rule(12,l) 


= "start" 


let 


rule(12,2) 


= "yes" 


73 


let 


rule(12,3) 


= "no" 


let 


rule(12,4) 


= "operating" 


74 


let 


rule(13,l) 


= "start" 


let 


rule(13,2) 


= "yes" 


75 


let 


rule(13,3) 


- "yes" 


let 


rule(13,4) 


= "operating" 


76 


let 


rule (14 ,1) 


= "" 


let 


rule (14 ,2) 


= nil 


77 


let 


rule(14,3) 


= "" 


let 


rule(14,4) 


= "standby*" 


78 


let 


rule(15,l) 


- nil 


let 


rule(15,2) 


= "no" 


79 


let 


rule(15,3) 


= II" 


let 


rule(15,4) 


= "operating*' 


80 


let 


rule(16,l) 


_ nil 


let 


rule(16,2) 


= "yes" 


81 


let 


rule(16,3) 


= "no" 


let 


rule(16,4) 


= "operating*' 
= II yes" 


82 


let 


rule(17,l) 


- II n 


let 


rule(17,2) 


83 


let 


rule(17,3) 


= "yes" 


let 


rule(17,4) 


= "operating*' 



84 let later. case = .yes 

85 always 

86 " 

87 " Determine input signal status. Assume that "start" and "stop" 

88 " commands cancel each other out (respective values of 1 and -1) . 

89 " 

90 for every signal in input. sset (component) 

91 do 

92 if signal .type (signal) eg "process" 

93 add 1 to total. process 

94 if strength (signal) eg .on 

95 add 1 to number. process 

96 always 

97 else 

98 if signal .type (signal) eg "power" 

99 add 1 to total. power 

100 if strength (signal) eg .on 

101 add 1 to number. power 

102 always 

103 else 

104 add 1 to tota 1 . command 

105 add strength (signal) to index. command 

106 always 

107 always 

108 loop 

109 " 

110 '' Develop test vector for comparison with rules. Assume that 
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111 '' a single process signal is sufficient, and that a single power 

112 " signal is sufficient (i.e., OR gates). 

113 " 

114 if index. command eg -1 

115 let test(l) => “stop" 

116 else 

117 if index. command eg 0 

118 let test(l) = "none" 

119 else 

120 let test(l) = "start" 

121 always 

122 always 

123 if number. power ge 1 

124 let test(2) = "yes" 

125 else 

126 let test (2) = "no" 

127 always 

128 if number. process ge 1 

129 let test (3) = "yes" 

130 else 

131 let test (3) = "no" 

132 always 

133 let test (4) = state (component) 

134 •• 

135 " Determine appropriate rule. 

136 " 

137 for ruletype = 1 to 17 

138 do 

139 for j = 1 to 4 

140 do 

141 if rule(ruletype, j ) ne "" and rule(ruletype, j ) ne test(j) 

142 go to 'next' 

143 always 

144 loop 

145 go to 'found' 

146 'next' 

147 loop 

148 " 

149 '' Select rule. 

150 " 

151 'found' 

152 select case ruletype 

153 

154 case 1, 16 

155 let state (component) = "failed" 

156 let output. strength = .no 

157 

158 case 2, 3, 4, 7 

159 let state (component) =* "standby" 

160 let output. strength = .no 

161 

162 case 5 

163 call demand. test giving component yielding success 

164 if success eg .no 

165 let state (component) =» "standby*" 







I 
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166 let output. strength = .no 

167 else 

168 let state (component) = "failed" 

169 let output. strength = .no 

170 always 

171 

172 case 6 

173 call demand. test giving component yielding success 

174 if success eq .no 

175 let state (component) = "standby*" 

176 let output. strength = .no 

177 else 

178 let state (component) = "operating" 

179 let output. strength = .yes 

180 always 

181 

182 case 8 

183 call demand. test giving component yielding success 

184 if success eq .no 

185 let state (component) = "failed" 

186 let output. strength = .no 

187 else 

188 let state (component) = "standby" 

189 let output. strength = .no 

190 always 

191 

192 case 9 

193 call demand. test giving component yielding success 

194 if success eq .no 

195 let state (component) = "operating*" 

196 let output. strength = .yes 

197 else 

198 let state (component) = "standby" 

199 let output. strength =• .no 

200 always 

201 

202 case 10, 12 

203 let state (component) = "failed" 

204 let output. strength = .no 

205 

206 case 11, 13 

207 let state (component) = "operating" 

208 let output . strength = .yes 

209 

210 case 14 

211 let state (component) = "standby*" 

212 let output . strength = .no 

213 

214 case 15 

215 let state (component) = "operating*" 

216 let output. strength = .no 

217 

218 case 17 

219 let state (component) = "operating*" 

220 let output. strength = .yes 
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221 

222 default 

223 " 

224 " Error messages can be put here if rule not matched. 

225 " 

226 endselect 

227 " 

228 " Update output signals. 

229 " 

230 for every signal in output. s set (component) 

231 let strength(signal) = output. strength 

232 

233 return 

234 

2 35 end "active 
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1 process availability 

2 " 

3 '' This process totals the sum of the system indicator 

4 " variable at the specified time points. At the completion 

5 " of all trials the totals are divided by the number of 

6 " trials to determine the time dependent system availability. 

7 " 

8 while time.v It (simulation. time + 10) 

9 do 

10 suspend 

11 add system. ind.var to time. avail .data (availability) 

12 loop 

13 

14 suspend 

15 

16 end "availability 
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1 process call. update 

This should be a process to keep the process component 
from destroying itself when it tries to call a system 
update. 

7 while time.v It .000004 

8 do 

9 wait .000005 hours 

10 for every component in system. cset 

11 do 

12 resume the component 

13 loop 

14 for every tank in system. tset 

15 resume the tank 

16 wait .0005 hours 

17 for i = 1 to dim. f (cptr(*) ) 

18 do 

19 if component. type (cptr ( i) ) eq "active" 

20 or component, type (cptr (i) ) eq "passive" 

21 if state(cptr(i) ) ne "operating" 

22 interrupt the component called cptr(i) 

23 always 

24 always. 

25 loop 

26 loop 

27 call system. update 

28 

2 9 return 

30 

31 end ' 'call. update 



' 'TANK 
"TANK 




% 
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routine check. valve given component 



Develops output signals for a check valve. 



input process 



output process 



9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 



Condensed decision table: 



Case 


Process 

Input 


Initial 

State 


Final 

State 


Process 

Output 


1 


_ 


failed_closed 


failed_closed 


no 


2 


no 


closed 


closed 


no 


3 


yes 


closed 


falled_closed 


no 


4 


no 


failed_open 


open 

failed_open 


yes 

no 


5 


yes 


failed_open 


failed_open 


yes 


6 


no 


open 


failed_open 


no 


7 


yes 


open 


closed 

open 


no 

yes 



define rule as a saved 2-dimensional text array 
define component as a pointer variable 
define number. process, total. process, output. strength, 
ruletype, success and j as integer variables 
define later. case as a saved integer variable 



Enter decision table. 



if later. case eg .no 

reserve rule as 7 by 2 
let rule(l,l) => 
let rule(2,l) = "no" 
let rule (3,1) - "yes" 
let rule (4,1) = "no" 
let rule (5,1) = "yes" 
let rule(6,l) = "no" 
let rule (7,1) = "yes" 
let later. case = .yes 
always 



let rule(l,2) 
let rule(2,2) 
let rule(3,2) 
let rule (4, 2) 
let rule(5,2) 
let rule(6,2) 
let rule(7,2) 



Determine input signal status. 



for every signal in input. sset (component) 
do 

if signal, type (signal) eg "process" 
add 1 to total. process 
if strength (signal) eg .on 
add 1 to number. process 
always 
always 
loop 



" failed_closed" 
"closed" 
"closed" 
"failed_open" 

" failed~open" 
"open" 

"open" 



■ -1 
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56 '' Develop test vector for comparison with rules. Assume that 

57 " a single process signal is sufficient (i.e., an OR gate). 

58 " 

59 if number. process ge 1 

60 let test(l) = "yes" 

61 else 

62 let test(l) = "no" 

63 always 

64 let test (2) = state (component) 

65 ' ' 

66 ' ' Determine appropriate rule. 

67 ' ' 

68 for ruletype = 1 to 7 

69 do 

70 for j = 1 to 2 

71 do 

72 if rule{ruletype, j ) ne "" and rule (ruletype, j ) ne test(j) 

73 go to 'next' 

74 always 

75 loop 

76 go to 'found' 

77 'next' 

78 loop 

79 " 

80 " Select rule. 

81 " 

82 'found' 

83 select case ruletype 

84 

85 case 1 

86 let state (component) = "failed_closed” 

87 let output. strength = .no 

88 

89 case 2 

90 let state (component) = "closed" 

91 let output .strength = .no 

92 

93 case 3 

94 call demand. test giving component yielding success 

95 if success eq .no 

96 let state (component) = "failed_closed" 

97 let output. strength = .no 

98 else 

99 let state (component) = "open" 

100 let output . strength = .yes 

101 always 

102 

103 case 4 

104 let state (component) = "failed_open" 

105 let output. strength = .no 

106 

107 case 5 

108 let state (component) = "failed_open" 

109 let output. strength - .yes 

110 
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111 case 6 

112 call demand. test giving component yielding success 

113 if success eq .no 

114 let state (component) "failed_open“ 

115 let output . strength = .no 

116 else 

117 let state (component) = "closed" 

118 let output . strength = .no 

119 always 

120 

121 case 7 

122 let state (component) = "open" 

123 let output. strength = .yes 

124 

125 default 

126 " 

127 " Error messages can be put here if rule not matched. 

128 " 

129 endselect 

130 " 

131 '' Update output signals. 

132 " 

133 for every signal in output. sset (component) 

134 let strength (signal) = output. strength 

135 

136 return 

137 

138 end ' 'check. valve 
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1 process component 

2 " 

3 " Tracks behavior of all components after initial demand (change). 

4 " Includes repair. Uses exponential failure time model. 

5 

6 define mean. failure. time, default. time, el, and 

7 e2 as real variables 

8 

9 'term' 

10 suspend 

11 while time.v It (simulation. time + 10) 

12 do 

13 'reset' 

14 let status (component) = .working 

15 if run. failure. frequency (component) gt 0 

16 let mean. failure. time =* 1. /run. failure. frequency (component) 

17 if run. type eq 1 

18 wait mean. failure. time hours 

19 go to 'repair' 

20 otherwise 

21 wait exponential. f (mean. failure. time, 1) hours 

22 'repair' 

23 if status (component) eq .resetting 

24 go to 'reset' 

25 always 

26 if status (component) eq .reset. run 

27 go to 'term' 

28 always 

29 if state (component) eq "open" or 

30 state (component) eq "closed" or 

31 state (component) eq "operating" 

32 let old. state (component) = state (component) 

33 let state (component) = failure. translation (component) 

34 activate a call. update now 

35 always 

36 else 

37 let default. time =« simulation. time + 10.0 

38 wait default. time hours 

39 if status (component) eq .resetting 

40 go to 'reset' 

41 always 

42 if status (component) eq .reset. run 

43 go to 'term' 

44 always 

45 always 

46 let status (component) = .awaiting. repair 

47 let failure. time (component) = time.v 

48 activate a repair. supervisor now 

49 suspend 

50 if status (component) eq .reset. run 

51 go to 'term' 

52 always 

53 " 

54 " 

55 " 



REPAIR 
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56 let status (component) = .under. repair 

57 let el •» repair. function. shape (component) 

58 let e2 - repair. function. scale (component) 

59 if run. type eq 1 

60 wait e2 hours 

61 go to 'good' 

62 otherwise 

63 wait weibull . f (el,e2, 1) hours 

64 'good' 

65 if status (component) eq .reset. run 

66 go to 'term' 

67 always 

68 let old.state(component) = state (component) 

69 select case component. type (component) 

70 

71 case "active", "passive" 

72 let state (component) = "standby" 

73 

74 case "switch" 

75 let state (component) = "open" 

76 

77 case "valve", "check. valve" 

78 let state (component) = "closed" 

79 

80 default 

81 print 1 line thus 

82 The component type was not matched in the repair routine. 

83 

84 endselect 

85 activate a call. update now 

86 loop 

87 

88 suspend 

89 

90 end ''component 
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1 routine demand. test given component yielding success 

2 " 

3 " Determines if given component succeeds or fails on demand, 

4 " using the demand. failure. frequency for the component. 

5 " 

6 define component as a pointer variable 

7 define success as an integer variable 

8 if random. f(l) le demand. failure. frequency (component) 

9 let success - .no 

10 else 

11 let success = .yes 

12 always 

13 

14 return 

15 

16 end "demand. test 
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1 process external . event 

2 " 

3 * ' Schedules a change in the system (either to component status 




6 while time.v It (simulation. time + 10) 

7 do 

a suspend 

9 for every component in extevnt.cset(external. event) 

10 do 

11 let old.state(component) = state (component) 

12 let state (component) = new. state(external. event) 

13 loop 

14 

15 if number. signals(external. event) eg 1 

16 for j = 1 to number. signals (external. event) 

17 do 

18 for every signal in system. sset 

19 with origin (signal) eg signal. origin (external. event) 

20 and destination (signal) eg 

21 s ignal . destination ( external . event ) 

22 and signal. type(signal) eg signal. typee (external. event) 

23 find the first case 

24 if found 

25 let old. strength (signal) = strength (signal) 

26 let strength (signal) = new. strength (external. event) 

27 always 

28 loop 

29 else 

30 if number. signals(external. event) ne 0 

31 print 1 line thus 

32 An external event was entered with more than one signal change. 

33 always 

34 always 

35 call system. update 

36 loop 

37 

38 suspend 

39 

40 end '' external . event 
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1 function failure. translation (component) 

2 " 

3 '' Determines status of "failed” component. 

4 •• 

5 define component as an integer variable 

6 define mode as a text variable 

7 

8 select case component. type (component) 

9 

10 case "active", "passive" 

11 let mode = "failed" 

12 

13 case "check. valve" , "valve", "switch" 

14 if state (component) eq "open" 

15 let mode =■ "failed_closed" 

16 always 

17 if state (component) eq "closed" 

18 let mode = "failed_open" 

19 always ~ 

20 if state (component) ne "open" and 

21 state (component) ne "closed" 

22 print 1 line thus 

23 Failure translation didn't function properlyl 

24 always 

25 

26 default 

27 print 1 line thus 

28 Failure translation routine rule not matched! 

29 

30 endselect 

31 

32 return with mode 

33 

34 end " failure. translation 



Dynamic Simulation Model 



211 



1 routine input 

2 ' ' 



3 '' Problem input routine. 

4 " 

5 define infile and outfile as text variables 

6 

7 write as /, "Enter DOS input file name => ",+ 

8 read infile 

9 write as /, "Enter DOS output file name => ",+ 

10 read outfile 

11 open 7 for input, file name = infile 

12 use 7 for input 

13 open 8 for output, file name = outfile 

14 use 8 for output 

15 ' ' 

16 •' Title, general characteristics. 

17 " 

18 read job. title as t 80, / 

19 write job. title as t 80, / 

20 read simulation. time as d(10,2), / 

21 write simulation. time as d(10,2), / 

22 read run. type as i 10, / 

23 write run. type as i 10, / 

24 read ntrial as i lo, / 

25 write ntrial as i 10, / 

26 read ntimes as i 10, / 

27 write ntimes as i 10, / 

28 read distribution. type as i 10, / 

29 write distribution. type as i 10, / 

30 reserve time_avail (*) as ntimes 

31 if distribution. type eg 0 

32 for i = 1 to ntimes 

33 do 

34 read time_avail(i) as d(10,2), / 

35 write time_avail(i) as d(10,2), / 

36 loop 

37 always 

38 " 

39 " Component characteristics. 

40 " 

41 read n. component. record as i 10, / 

42 write n. component. record as i 10, / 

43 create every component. record 

44 reserve input. name (*,*) , output. name (*,*) , input . signal. type (*,*) , 

45 output.signal.type(*, *) , input. signal. strength (*,*) , and 

46 output. signal. strength (*,*) as n. component . record by * 

47 for i = 1 to n. component. record 



48 do 



49 

50 

51 

52 

53 

54 

55 



read component_name (i) , 



component_type ( i) , 
initial_state(i) , 



number_inputs(i) , and 



number_outputs ( i j 
as 3 t 10, 2 i 5, / 



write component_name(i) , 
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5 6 component_type ( i ) , 

57 initial_state(i) , 

58 number_inputs(i) , and 

59 number_outputs(i) 

60 as 3 t 10, 215,/ 

61 read demand_failure_frequency (i) and 

62 run_failure_freguency (i) 

63 as 2 d(10,5) , / 

64 write demand_failure_frequency (i) and 

65 run_failure_frequency (i) 

66 as 2 d(10,5) , / 

67 read repair_function_shape(i) , 

68 repair~function~scale(i) , and 

69 repair_probability (i) 

70 as 3 d(10,5) , / 

71 write repair_function_shape(i) , 

72 repair_function_scale(i) , and 

73 repair_probability(i) 

74 as 3 d(10,5) , / 

75 " 

76 '' Input signals for component. 

77 " 

78 reserve input.name(i,*) , 

79 input.signal.type(i,*) , and 

80 input. signal. strength (i,*) 

81 as number_inputs(i) 

82 for j - 1 to number_inputs(i) 

83 do 

84 read input.name(i, j) , 

85 input. signal. type(i, j) , and 

86 input. signal. strength (i,j) 

87 as b 11, 2 t 10, i 5, / 

88 write input.name(i, j) , 

89 input. signal. type ( i, j) , and 

90 input. signal. strength (i,j) 

91 as b 11, 2 t 10, i 5, / 

92 if trim. f( input. name(i,j) ,0) eg "system" 

93 add 1 to total. signal. count 

94 always 

95 loop 

96 ' ' 

97 '' Output signals for components. 

98 ' ' 



99 reserve output.name(i, *) , 

100 output.signal. type(i,*) , and 

101 output.signal.strength(i, *) 

102 as number_outputs ( i ) 

103 for j = 1 to number_outputs(i) 

104 do 

105 read output.name(i, j) , 

106 output.signal.type(i, j) , and 

107 output. signal. strength (i,j) 

108 as b 11, 2 t 10, i 5, / 

109 write output.name(i, j) , 

110 output. signal. type ( i, j) , and 
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111 

112 

113 

114 

115 

116 

117 

118 

119 

120 
121 
122 

123 

124 

125 

126 

127 

128 

129 

130 

131 

132 

133 

134 

135 

136 

137 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 
161 
162 

163 

164 

165 



output . signal . strength ( i , j ) 
as b 11, 2 t 10, i 5, / 

loop 

add number_outputs(i) to total . signal . count 
loop 

System characteristics. 

read initial . system. state as t 10, / 
write initial .system. state as t 10, / 
read system. success. criterion as i 10, / 
write system. success. criterion as i 10, / 

External event records. 

read n. external. event. record as i 10, / 
write n. external. event. record as i 10, / 
if n. external .event. record gt 0 

create every external . event. record 

reserve extevnt.component (*, *) , extevnt.origin(*, *) , and 
extevnt . destination (*,*), extevnt . stype ( * , * ) 
as n. external. event. record by * 

for i = 1 to n. external .event. record 
do 

read occurrence_time(i) as d(10,2) 
write occurrence_time(i) as d(10,2) 
read number_components(i) as i 10, / 
write number_components(i) as i 10, / 
if number_components (i) gt 0 

reserve extevnt.component(i, *) as number_components (i) 
for j = 1 to number_components ( i) 
do 

read extevnt. component (i,j) as t 10 
write extevnt.component(i, j) as t 10 
loop 

read new_state(i) as /, t 10, / 
write new_state(i) as /, t 10, / 
always 

read number_signals(i) as 1 10, / 
write number_signals ( i) as i 10, / 
if number_signals(i) gt 0 

reserve extevnt.origin(i,*) , extevnt.destination(i, *) , 
ext evnt.s type ( i, *) as number_signals ( i) 
for j = 1 to number_signals(i) 
do 

read extevnt . or igin ( i , j ) , 

extevnt. destination (i,j) , 
extevnt . stype ( i , j ) 
as 3 t 10, / 

write extevnt. origin ( i, j ) , 

extevnt . destination ( i , j ) , 
extevnt . stype ( i , j ) 
as 3 t 10, / 

loop 
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166 read new_strength ( i ) as i 10, / 

167 write new_strength(i) as i 10, / 

168 always 

169 loop 

170 always 

171 

172 end ''input 




if'L 
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2 

3 



6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 



routine passive given component 



Develops output signals for a passive component (no explicit 
command signals or power source) . 



input process 



output process 



Condensed decision table: 



Process Initial 
Case Input State 



Final Process 
State Output 



2 

3 



no 

yes 

no 

yes 



failed 

standby 

standby 

operating 

operating 



failed 

standby 

failed 

operating 

standby 

operating 



no 

no 

no 

yes 

no 

yes 



define rule as a saved 2-dimensional text array 
define component as a pointer variable 
define number. process, total. process, output. strength, 
ruletype, success, and j as integer variables 
define later. case as a saved integer variable 

Enter decision table. 



if later. case eq .no 

reserve rule as 5 by 2 
let rule (1,1) = "" 
let rule (2,1) = "no" 
let rule(3,l) = "yes" 
let rule (4,1) = "no" 
let rule (5,1) “ "yes" 
let later. case « .yes 
always 



let rule(l,2) 
let rule(2,2) 
let rule (3, 2) 
let rule(4,2) 
let rule(5,2) 



Determine input signal status. 



for every signal in input . sset (component) 
do 

if signal. type (signal) eq "process" 
add 1 to total. process 
if strength (signal) eq .on 
add 1 to number. process 
always 
always 
loop 



"failed" 

"standby" 

"standby" 

"operating* 

"operating* 



Develop test vector for comparison with rules. Assume that 
a single process signal is sufficient (i.e., an OR gate). 



if number .process ge 1 
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56 let test(l) = "yes" 

57 else 

58 let test(l) = "no" 

59 always 

60 let test(2) = state (component) 

61 ' ' 

62 " Determine appropriate rule. 

63 " 

64 for ruletype = 1 to 5 

65 do 

66 for j = 1 to 2 

67 do 

68 if rule (ruletype, j) ne "" and rule(ruletype, j) ne test(j) 

69 go to 'next' 

70 always 

71 loop 

72 go to 'found' 

73 'next' 

74 loop 

75 " 

76 " Select rule. 

77 " 

78 'found' 

79 select case ruletype 

80 

81 case 1 

82 let state (component) = "failed" 

83 let output. strength = .no 

84 

85 case 2 

86 let state (component) = "standby" 

87 let output. strength = .no 

88 

89 case 3 

90 call demand. test giving component yielding success 

91 if success eq .no 

92 let state (component) = "failed" 

93 let output. strength = .no 

94 else 

95 let state (component) = "operating" 

96 let output. strength = .yes 

97 always 

98 

99 case 4 

100 let state (component) = "standby" 

101 let output. strength = .no 

102 

103 case 5 

104 let state (component) = "operating" 

105 let output. strength = .yes 

106 

107 default 

108 " 

109 " Error messages can be put here if rule not matched. 

110 " 







s 
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111 endselect 

112 " 

113 " Update output signals. 

114 " 

115 for every signal in output. sset (component) 

116 let strength (signal) = output. strength 

117 

118 return 

119 

120 end "passive 
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1 process repair . supervisor 

2 " 

3 '' This process can be modified in the future to determine 

4 '' when a failed component should begin the repair process. 

5 " Time delays can be inserted (repair delays) and if repair 

6 '' resources are limited the number of components under 

7 " repair at any given time can be controlled here. 



9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 



Currently this routine will be called from the system. update 
routine every time a new failure is detected. This routine 
uses the repair. probability for the failed component to 
determine if the component is repairable or not. If the 
component is repairable a repair is then begun immediately. 

To determine what the current status of each component is 
the status variable can be checked. The status will be 
working, resetting, awaiting repair, under repair, or not 
repairable. 

This portion is for defining a repair delay. 

define component as a pointer variable 
define a, b, and x as real variables 
let a = 1.0 
let b =• 100.0 
let X = time.v 
if run. type eg 1 
wait b hours 
let a = 0.0 
go to 'good' 
otheirwise 

wait weibull.f (a,b,l) hours 
'good' 

If it is desireable to use various repair delays on a frequent 
basis, the program could be modified to read in the repair 
delay distribution parameters. The above delay is a weibull 
distribution, but with the parameters chosen, it is actually 
an exponential distribution. 

for every component in system. cset 
with failure. time (component) eq x 
find the first case 
if found 

if status (component) = .awaiting. repair 

if random. f(l) le repair. probability (component) 
resume the component 
else 

let status (component) = .not. repairable 
always 
always 

let failure. time(component) = -1.0 
else 

print 1 line thus 

In repair supervisor routine the component to repair was not IDed. 
always 
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56 

57 return 

58 

59 end "repair. supervisor 
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1 routine run. initialize 

2 ' ' 

3 '' initialization of components, signals, and external events 

4 ' ' 

5 define i, j, k, and signal. count as integer variables 

6 define x, y, and z as real variables 

7 ' ' 

8 ' ' Component initialization. 

9 •• 

10 reserve cptr(*) as n. component. record 

11 for i = 1 to n. component. record 

12 do 

13 activate a component called cptr(i) now 

14 file cptr(i) in system. cset 

15 let name(cptr(i) ) = trim. f (component_name (i) , 0) 

16 let component. type (cptr( i) ) = trim. f (component_type (i) , 0) 

17 let n. input. sset(cptr(i) ) => number_inputs (i) 

18 let n. output. sset (cptr ( i) ) => number_outputs (i) 

19 let demand. failure. frequency (cptr (i) ) = 

20 demand_failure_frequency (i) 

21 let run. failure. frequency (cptr (i) ) = run_failure_frequency (i) 

22 let repair. probability (cptr ( i) ) = repair_probability(i) 

23 let repair. function. shape(cptr(i) ) = repair_function_shape (i) 

24 let repair. function. scale(cptr(i) ) = repair_function_scale (i) 

25 

26 select case component. type (cptr ( i) ) 

27 

28 case "active" 

29 let response. function (cptr (i) ) = 'active' 

30 

31 case "passive" 

32 let response. function(cptr(i) ) = 'passive' 

33 

34 case "valve" 

35 let response. function(cptr(i) ) = 'valve' 

36 

37 case "check_valve" 

38 let response. function (cptr ( i) ) => 'check. valve' 

39 

40 case "switch", "breaker" 

41 let response. function (cptr ( i) ) = 'switch' 

42 

43 default 

44 let response, function (cptr (i) ) =• 'active' 

45 print 1 line with name ( cptr ( i ) ) thus 

46 In initialize routine response function not matched to ******* 

47 

48 ends elect 

49 

50 loop 

51 add 5 to total . signal .count '' 

52 reserve sptr(*) as total. signal. count 

53 " 

54 " Initialize and file boundary condition signals. 



Dynamic Simulation Model 



221 



56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 
101 
102 

103 

104 

105 

106 

107 

108 

109 

110 



for j = 1 to n. component. record 
do 

for k = 1 to number_inputs ( j ) 
do 

if trim. f (input. name(j ,k) ,0) eq "system" 
add 1 to signal. count 

create a signal called sptr( signal .count) 
let signal. type (sptr (signal. count ) ) = 
trim . f ( input . signal . type ( j , k) , o ) 
let origin (sptr (signal. count ) ) = "system" 
let destination(sptr(signal.count) ) = 
trim . f ( component_name ( j ) , 0 ) 
file sptr (signal. count) in input.sset(cptr(j) ) 
file sptr (signal. count) in system. boundary. sset 
file sptr (signal. count) in system. sset 
always 
loop 
loop 

Initialize and file component output signals. 

for j = 1 to n. component. record 
do 

for k = 1 to number_outputs(j) 
do 

add 1 to signal. count 

create a signal called sptr (signal .count) 
let signal. type(sptr(signal. count) ) = 
trim. f (output. signal. type(j ,k) ,0) 
let origin(sptr(signal.count) ) = trim. f (component_name ( j ) , 0) 
let destination(sptr(signal.count) ) = 
trim. f (output. name (j ,k) ,0) 
for every component in system. cset 

with name (component) eq destination (sptr (signal. count) ) 
find the first case 
if found 

file sptr (signal .count) in input. sset (component) 
else 

if destination(sptr(signal.count) ) eq "system" 
file sptr (signal. count) in system. success. sset 
always 
always 

file sptr (signal. count) in output. sset (cptr(j ) ) 
file sptr (signal. count) in system. sset 
loop 
loop 

Create and initialize external events, using 
permanent entity external . event. record. 

if n. external. event. record gt 0 

reserve eptr(*) as n. external. event. record 
for i = 1 to n. external. event. record 
do 

activate an external. event called eptr(i) now 
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111 let occurrence. time (eptr ( i) ) = occurrence_time (i) 

112 add .001 to occurrence. time (eptr ( i) ) 

113 let new. state { eptr (i) ) = trim. f (new_state (i) , 0) 

114 for j = 1 to number_components { i ) 

115 do 

116 for every component in system. cset 

117 with name (component) eq trim. f (extevnt. component (i , j ), 0) 

118 find the first case 

119 if found 

120 file component in extevnt. cset (ep tr ( i) ) 

121 always 

122 loop 

123 let new. strength (eptr ( i) ) = new_strength(i) 

124 let number. signals (eptr ( i) ) = number_signals (i) 

125 if number. signals ( eptr ( i) ) eq 1 

126 let signal. origin(eptr(i) ) = trim. f (extevnt. origin (i, 1) , 0) 

127 let signal. destination(eptr(i) ) = 

128 trim. f (extevnt. destination(i, 1) ,0) 

129 let signal. typee (eptr ( i) ) = trim. f (extevnt . stype (i , 1) , 0) 

130 always 

131 file eptr(i) in system. eset 

132 loop 

133 always 

134 

135 reserve test as 4 

136 reserve signal. status (*] as dim. f (sptr (*) ) 

137 reserve unavailability. dist(*) as ntrial 

138 reserve aptr(*) as ntimes 

139 if distribution. type eq 1 

140 let X = simulation. time / (ntimes - 1) 

141 let time_avail (1) = 0. 

142 for i = 2 to ntimes 

143 do 

144 let time_avail (i) = (i - l) * x 

145 loop 

146 always 

147 if distribution. type eq 2 

148 let y = log. 10. f (simulation. time) 

149 let X = y / (ntimes - 1) 

150 let time_avail(l) = 0. 

151 for i = 2 to ntimes 

152 do 

153 let z = (i - 1) * X 

154 let time_avail (i) = 10 ** z 

155 loop 

156 always 

157 for i = 1 to ntimes 

158 do 

159 activate an availability called aptr(i) now 

160 let time.avail(aptr(i) ) = time_avail ( i) 

161 loop 

162 

163 return 

164 

165 end "run. initialize 







it 






i 



-1 
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1 routine run. output 

2 " 

3 '' This routine will print the output report at the end of the 

4 '' run. It prints the time dependent unavailability data and the 

5 '' average unavailability distribution data. 

6 ' ' 

7 define x as a real variable 

8 

9 for i = 1 to ntimes 

10 do 

11 let X = time. avail. data(aptr(i) ) 

12 let time.avail.data(aptr(i) ) = x / ntrial 

13 let X = 1 - time. avail. data (aptr(l) } 

14 let time. avail. data(aptr(i) ) = x 

15 loop 

16 

17 write as *,/,/ 

18 print 6 lines with ntrial thus 

19 AFTER **** TRIALS 

20 

21 THE TIME DEPENDENT UNAVAILABILITY IS AS FOLLOWS 

22 

23 TIME UNAVAILABILITY 

24 

25 for i = 1 to ntimes 

26 do 

27 print 2 lines with time.avail(aptr(i) ) 

28 and time. avail . data (aptr( i) ) thus 

29 

30 *****.** *.**** 

31 loop 

32 " 

33 '' Sort the average unavailability distribution data. 

34 " 

35 define 1, m, n, j, k, and im as integer variables 

36 define xp as a real variable 

37 

38 let m =» ntrial 

39 'sortl' 

40 let 1 = m 

41 let m = div.f(l,2) 

42 if m gt 0 

43 let k = ntrial - m 

44 for j = 1 to k 

45 do 

46 let n = j 

47 'sort 2' 

48 let im = n + m 

49 if unavailability. dist(n) gt unavailability. dist(im) 

50 let xp = unavailability. dist(n) 

51 let unavailability. dist(n) = unavailability. dist(im) 

52 let unavailability. dist(im) = xp 

53 let 1 = n 

54 let n = 1 - m 

55 if n gt 0 



mic 
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go to 'sort2' 
otherwise 
always 
loop 

if m gt 0 

go to 'sortl' 
otherwise 
always 

write as *,/,/ 

print 6 lines with ntrial and simulation. time thus 
AFTER **** TRIALS 
AND 

OVER A TIME PERIOD OF ***** HOURS 
THE AVERAGE SYSTEM UNAVAILABILITY IS AS FOLLOWS 



define xl, x5, x25, x40, x50, x60, x75, x95, and x99 
as integer variables 
let xl = div.f (ntrial, 100) 
let X = 5 * ntrial 
let x5 - div.f(x,100) 
let X - 25 * ntrial 
let x25 = div.f(x,100) 
let X = 40 * ntrial 
let X40 = div.f(x,100) 
let x50 = div. f (ntrial, 2) 
let X = 60 * ntrial 
let x60 = div.f(x,100) 
let X = 75 * ntrial 
let x75 =• div.f(x,100) 
let X = 95 * ntrial 
let X95 = div.f(x,100) 
let X = 99 * ntrial 
let x99 = div.f(x,100) 
if xl eg 0 
let xl - 1 
always 
if x5 eq 0 
let x5 = 1 
always 

print 27 lines with minimum.unavailability, unavailability. dist (xl) , 
unavailability. dist(x5) , unavailability. dist (x25) , 
unavailability. dist(x40) , unavailability. dist (x50) , 
unavailability. dist (x60) , unavailability. dist (x75) , 
unavailability. dist(x95) , unavailability. dist (x99) , 
maximum. unavailability, average. unavailability, 
and variance. unavailability thus 

The minimum is: 

The 1st percentile is: 

The 5th percentile is: 
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111 


The 


25th 


percentile 


is: 




112 

113 


The 


40 th 


percentile 


is: 


* . **** 


114 

115 


The 


50th 


percentile 


is: 


★ . **** 


116 

117 


The 


60th 


percentile 


is: 


**** 


118 

119 


The 


75 th 


percentile 


is: 


•k 


120 

121 


The 


95 th 


percentile 


is: 


* 


122 

123 


The 


99th 


percentile 


is: 


k ^kkkk 


124 

125 


The 


maximum is: 




k.kkkk 


126 

127 


The 


mean 


is: 




k , **** 


128 

129 


The 


variance is: 




* . kkkk 



130 

131 " 

132 " Use this portion to print out all of the average system 

133 " unavailability values, one for every trial. These are the 

134 " values on which the above percentiles are based. 

135 " 

136 " write as *,/,/ 

137 " for i = 1 to ntrial 

138 " do 

139 " print 1 line with i and unavailability. dist(i) thus 

140 " point **** is *.**** 

141 " loop 

142 

143 end "run. output 
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1 process schedule. avail. samples 

2 " 

3 " This process will cause samples to be taken at the designated 

4 ' ' times during each trial to compute the time dependent 

5 " availability of the system. 

6 " 

7 define x as a real variable 

8 

9 wait .002 hours 

10 resume the availability called aptr(l) 

11 for i = 2 to ntimes 

12 do 

13 let X - time.avail (aptr (i) ) - time. avail (aptr(i - 1)) 

14 wait X hours 

15 resume the availability called aptr(i) 

16 loop 

17 

18 return 

19 

20 end ' 'schedule. avail. samples 
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1 process schedule. external. events 

2 " 

3 " Schedules external events. 

4 " 

5 define i as an integer variable 

6 define x as a real variable 

7 

8 if n. external. event. record gt 0 

9 wait occurrence. time ( eptr ( 1) ) hours 

10 resume the external . event called eptr(l) 

11 for i = 2 to dim.f (eptr(*) ) 

12 do 

13 let X = occurrence. time(eptr(i) ) - occurrence. time (eptr ( i - 1)) 

14 wait X hours 

15 resume the external. event called eptr(i) 

16 loop 

17 always 

la 

19 return 

20 

21 end "schedule. external. events 
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1 process stop. scenario 



This process will interrupt any external events or components 
still scheduled to occur later in time. It then resets all 
components so they can begin operation again in the next trial. 

call system. update 



9 for every external. event in ev.s(i. external. event) 

10 interrupt external. event 

11 

12 for every component in ev.s(i. component) 

13 do 

14 interrupt component 

15 let time, a (component) => 0.0 

16 loop 

17 

18 for every component in system. cset 

19 do 

20 let status (component) - .reset. run 

21 resume component 

22 loop 

23 

24 return 

25 

2 6 end "stop. scenario 
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22 
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27 

28 

29 
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31 

32 

33 

34 

35 
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37 
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39 

40 

41 

42 

43 

44 

45 
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47 

48 
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52 

53 

54 

55 



routine switch given component 



Develops output signals for a switch or breaker 
using explicit command signals. Assumes that the component 
has one or more command signal inputs, power inputs, and 
process inputs: 



input command 
input power 
input process 



output process 



Condensed decision table: 





Command 


Power 


Process 


Initial 


Final 


Process 


'Case 


Input 


Input 


Input 


State 


State 


Output 


' 1 


- 


- 




failed_open 


failed_open 


no 


' 2 


- 


no 


- 


open 


open 


no 


' 3 


open 


- 


- 


open 


open 


no 


' 4 


none 


- 


- 


open 


open 


no 


' 5 


close 


yes 


no 


open 


failed_open 


no 












closed 


no 


' 6 


close 


yes 


yes 


open 


failed_open 


no 












closed 


yes 


' 7 


- 


- 


no 


failed_closed 


failed_closed 


no 


' 8 


- 


- 


yes 


failed_closed 


failed_closed 


yes 


' 9 


- 


no 


no 


closed 


closed 


no 


' 10 


- 


no 


yes 


closed 


closed 


yes 


' 11 


open 


yes 


no 


closed 


failed_closed 


no 












open 


no 


' 12 


open 


yes 


yes 


closed 


failed_closed 


yes 












open 


no 


' 13 


none 


- 


no 


closed 


closed 


no 


' 14 


none 


- 


yes 


closed 


closed 


yes 


' 15 


close 


- 


no 


closed 


closed 


no 


' 16 


close 


- 


yes 


closed 


closed 


yes 



define rule as a saved 2-dimensional text array 
define component as a pointer variable 

define index. command, >total. command, number. power, total. power, 
number. process, total. process, output . strength, ruletype, 
success and j as integer variables 
define later. case as a saved integer variable 



Enter decision table. 



if later. case eq .no 

reserve rule as 16 by 4 
let rule(l,l) = "" 
let rule(l,3) = 
let rule(2,l) = "" 
let rule(2,3) = "" 
let rule (3,1) = "open" 
let rule(3,3) = "" 
let rule (4,1) = "none" 



let rule(l,2) 
let rule (1,4) 
let rule (2, 2) 
let rule(2,4) 
let rule(3,2) 
let rule (3, 4) 
let rule(4,2) 



failed_open" 

no" 

open" 

open" 
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56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 
101 
102 

103 

104 

105 

106 

107 

108 

109 

110 



let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

let 

always 



rule(4,3) = 
rule(5,l) = 
rule(5,3) = 
rule(6,l) = 
rule(6,3) = 
rule(7,l) = 
rule(7,3) = 
rule(8,l) - 
rule(8,3) = 
rule(9,l) = 
rule(9,3) = 
rule(10,l) 
rule(10,3) 
rule (11, 1) 
rule(ll,3) 
rule(12,l) 
rule (12, 3) 
rule(13,l) 
rule(13,3) 
rule(14, 1) 
rule (14, 3) 
rule(15,l) 
rule (15, 3) 
rule(16,l) 
rule(l6,3) 
later. case 



"close" 

"no" 

"close" 

"yes" 

"no" 

"yes" 

"no" 

= "yes" 

= "open" 

= "no" 

= "open" 

= "yes" 

= "none" 

= "no" 

= "none" 

- "yes" 

=» "close" 
= "no" 

= "close" 
=* "yes" 

= .yes 



let 


rule (4, 4) = 


"open" 


let 


rule(5,2) = 


"yes" 


let 


rule (5, 4) = 


"open" 


let 


rule(6,2) = 


"yes" 


let 


rule (6, 4) = 


"open" 


let 


rule(7,2) = 


II II 


let 


rule (7, 4) = 


"failed_closed' 


let 


rule(8,2) = 


nil 


let 


rule (8,4) =» 


"failed closed' 


let 


rule (9,: 


2) = 


"no" 


let 


rule(9,‘ 


i) = 


"closed" 


let 


rule(10 


,2) 


a nrvQn 


let rule(10 


,4) 


= "closed" 


let 


rule(ll 


,2) 


= "yes" 


let 


rule (11 


,4) 


= "closed" 


let 


rule(12 


,2) 


= "yes" 


let 


rule (12 


»4) 


= "closed" 


let 


rule(13 


,2) 


= "" 


let rule(13 


»4) 


= "closed" 


let 


rule(14 


,2) 


_ nil 


let 


rule(14 


,4) 


- "closed" 


let 


rule (15 


,2) 


-> I'*' 


let 


rule(15 


,4) 


= "closed" 


let 


rule(16 


,2) 


= nil 


let rule(16 


,4) 


= "closed" 



Determine input signal status. Assume that "open" and "close" 
commands cancel each other out (respective values of 1 and -1) . 

for every signal in input. sset (component) 
do 

if signal. type(signal) eg "process" 
add 1 to total. process 
if strength (signal) eg .on 
add 1 to number. process 
always 
else 

if signal. type (signal) eg "power" 
add 1 to total. power 
if strength (signal) eg .on 
add 1 to number. power 
always 
else 

add 1 to total .command 
add strength (signal) to index. command 
always 
always 
loop 



Develop test vector for comparison with rules. Assume that 
a single process signal is sufficient, and that a single power 
signal is sufficient (l.e., OR gates). 
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111 if index. command eq -1 

112 let test(l) = "close" 

113 else 

114 if index. command eq 0 

115 let test(l) = "none" 

116 else 

117 let test(l) = "open" 

118 always 

119 always 

120 if number. power ge 1 

121 let test (2) = "yes" 

122 else 

123 let test(2) - "no" 

124 always 

125 if number. process ge 1 

126 let test(3) = "yes" 

127 else 

128 let test (3) = "no" 

129 always 

130 let test(4) = state (component) 

131 " 

132 " Determine appropriate rule. 

133 " 

134 for ruletype = 1 to 16 

135 do 

136 for j =■ 1 to 4 

137 do 

138 if rule ( ruletype, j) ne "" and rule (ruletype, j ) ne test(j) 

139 go to 'next' 

140 always 

141 loop 

142 go to 'found' 

143 'next' 

144 loop 

145 " 

146 " Select rule. 

147 " 

148 'found' 

149 select case ruletype 

150 

151 case 1 

152 let state (component) = "failed_open" 

153 let output. strength = .no 

154 

155 case 2, 3, 4 

156 let state (component) = "open" 

157 let output. strength = .no 

158 

159 case 5 

160 call demand. test giving component yielding success 

161 if success eq .no 

162 let state (component) = "failed_open" 

163 let output. strength = .no 

164 else 

165 let state (component) »» "closed" 
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166 let output. strength = .no 

167 always 

168 

169 case 6 

170 call demand. test giving component yielding success 

171 if success eq .no 

172 let state (component) = " failed_open" 

173 let output. strength = .no 

174 else 

175 let state (component) - "closed" 

176 let output . strength =■ .yes 

177 always 

178 

179 case 7 

180 let state (component) = "failed_closed" 

181 let output. strength = .no 

182 

183 case 8 

184 let state (component) = "failed_closed" 

185 let output. strength = .yes 

186 

187 case 9, 13, 15 

188 let state (component) = "closed" 

189 let output. strength = .no 

190 

191 case 10, 14, 16 

192 let state (component) = "closed" 

193 let output. strength = .yes 

194 

195 case 11 

196 call demand. test giving component yielding success 

197 if success eq .no 

198 let state (component) = "failed_closed" 

199 let output. strength =» .no 

200 else 

201 let state (component) * "open" 

202 let output. strength = .no 

203 always 

204 

205 case 12 

206 call demand. test giving component yielding success 

207 if success eq .no 

208 let state (component) =• "failed_closed" 

209 let output. strength - .yes 

210 else 

211 let state (component) = "open" 

212 let output. strength = .no 

213 always 

214 

215 default 

216 " 

217 '' Error messages can be put here if rule not matched. 

218 ' ' 

219 

220 " 



endselect 
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221 " Update output signals. 

222 " 

223 for every signal in output. sset( component) 

224 let strength (signal) = output. strength 

225 

226 return 

227 

228 end ''switch 
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routine system. update 

'' Updates status of signals in system, given status of all components 
' ' Performs iterations until signals stabilize or number of iterations 
'' is exceeded. 

" Notes: 

'' 1) Currently, maximum is set by number of signals. Later 

'' versions might make use of digraph/Petri net results. 

•' 2) Current version re-analyzes every component. Later versions 

'' might only re-analyze components whose input changes. 

define rf as a subprogram variable 
define i, itr, max.itr and number. success 
as integer variables 

for i = 1 to dim. f (sptr (*) ) 

let signal. status (i) = strength (sptr (i) ) 

let max.itr = dim. f (sptr (*) ) 
for itr = 1 to max.itr 
do 

' ' 1) Check for changed component states and changed input 

'' signals. 

'' 2) If found, place a demand on the component, and determine 

" component response. (Later versions may activate signals 

' ' here) . Note that since output signals are updated 

'' in routine response. function , input signals for 

" downstream components are also updated. 

for every component in system. cset 
do 

if state (component) ne old. state (component) 
let rf = response. function (component) 
call rf giving component 
always 

for every signal in input. sset (component) 

with strength (signal) ne old. strength (signal) 
find the first case 
if found 

let rf = response. function (component) 
call rf giving component 
always 

loop 

'' Quit iteration if no changes to entire set of signals. 

for i = 1 to dim. f (sptr (*) ) 

with strength ( sptr ( i) ) ne signal . status ( i) 
find the first case 
if found 

for i = 1 to dim. f( sptr (*) ) 

let signal. status (i) = strength ( sptr ( i) ) 

else 
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56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 
101 
102 

103 

104 

105 

106 

107 

108 

109 

110 



go to 'update' 
always 

loop 

print 2 lines with 24*time.v thus 

111 Error: Iteration maximum exceeded in routine system. update 

time = ****.*** hours. 

Activate newly started components, interrupt newly stopped 
components. 

'update' 

for every component in system. cset 

do 

if status (component) eg .working 

if state (component) ne old. state (component) 
select case component. type (component) 

case "active", "passive" 

if state (component) eg "failed" 

or state (component) eg "standby*" 
or state (component) eg "operating*" 
if old. state (component) eg "operating" 
interrupt the component 
always 

let time. a (component) = 0.0 
resume the component 
always 

if state (component) eg "standby" 

and old. state (component) eg "operating" 
interrupt the component 
always 

if state (component) eg "operating" 

and old. state (component) eg "standby" 
let time. a (component) = 0.0 
let status (component) = .resetting 
resume the component 
always 

case "check. valve", "switch", "valve" 
if state (component) eg "closed" 

and old. state (component) eg "open" 
let status (component) = .resetting 
interrupt the component 
let time. a (component) = 0.0 
resume the component 
always 

if state (component) eg "open" 

and old. state (component) eg "closed" 
let status (component) = .resetting 
interrupt the component 
let time. a (component) = 0.0 
resume the component 
always 

if state (component) eg "failed_open" 

or state (component) eg "failed_closed" 



I 
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111 interrupt the component 

112 let time. a (component) = 0.0 

113 resume the component 

114 always 

115 

116 default 

117 print 1 line thus 

118 When performing the system. update, no matching case! 

119 

120 endselect 

121 always 

122 always 

123 loop 

124 " 

125 '' Update status of system, components and signals. 

126 " 

127 for every signal in system. success. sset 

128 do 

129 if strength (signal) eq .on 

130 add 1 to number. success 

131 always 

132 loop 

133 if number. success ge system. success. criterion 

134 let system. state = "good" 

135 let system. ind.var = 1 

136 else 

137 let system. state - "failed" 

138 let system. Ind.var = 0 

139 always 

140 

141 call flow. update giving tptr(l) 

142 

143 for every component in system. cset 

144 let old. state (component) = state (component) 

145 

146 for every signal in system. sset 

147 let old. strength (signal) - strength (signal) 

148 

149 return 

150 

151 end ' 'system. update 



"TANK 
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1 routine trial. initialize 

2 " 

3 " This routine initializes the state of each component 

4 ' ' and the strength of each signal at the beginning of 

5 " a trial. 

6 " 

7 define i, j, and k as integer variables 



9 let system. state = trim. f ( initial. system. state, 0) 

10 if system. state eq "operating" 

11 let system. ind.var = 1 

12 else 

13 let system. ind.var = 0 

14 always 

15 " 

16 " Component state initialization. 

17 " 

18 for i = 1 to n. component. record 

19 do 

20 let old.state(cptr(i) ) = trim.f (initial_state(i) ,0) 

21 let state(cptr(i) ) = old.state(cptr(i) ) 

22 loop 

23 " 

24 " Signal strength initialization. 

25 " 

26 for i = 1 to n. component. record 

27 do 

28 for j = 1 to number_inputs ( i) 

29 do 

30 for every signal in system. sset 

31 with origin (signal) eq "system" 

32 and destination(signal) eq trim. f (component_name (i) , 0) 

33 and signal .type (signal) eq trim. f (input.signal .type ( i, j ) ,0) 

34 find the first case 

35 if found 

36 let strength (signal) = input.signal .strength (i , j ) 

37 always 

38 loop 

39 for k = 1 to number_outputs(i) 

40 do 

41 for every signal in system. sset 

42 with origin(signal) eq trim. f (component_name (i) , 0) 

43 and destination (signal) eq trim. f (output. name (i , k) , 0) 

44 and signal .type (signal) eq trim. f (output. signal .type (i, k) , 0) 

45 find the first case 

46 if found 

47 let strength(signal) = output. signal. strength (i,k) 

48 always 

49 loop 

50 loop 

51 

52 return 

53 

54 end "trial . initialize 
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routine valve given component 

'• Develops output signals for an MOV or manual valve 
'' using explicit command signals. Assumes that the component 
" has one or more command signal inputs, power inputs, and 
'' process inputs: 



input command 
input power 
input process 



output process 



Condensed decision table: 



Command 
Case Input 



Power Process 
Input Input 



Initial 

State 



Final Process 

State Output 



2 

3 close 

4 none 

5 open 

6 open 

7 

8 
9 

10 

11 close 

12 close 

13 none 

14 none 

15 open 

16 open 



no 



yes 

yes 



no 

no 

yes 

yes 



failed_closed 

- closed 

- closed 
closed 

no closed 

yes closed 

no failed_open 

yes failed_open 

no open 

yes open 

no open 

yes open 

no open 

yes open 

no open 

yes open 



failed_closed 

closed 

closed 

closed 

failed_closed 

open 

failed_closed 

open 

failed_open 

failed_open 

open 

open 

failed_open 

closed 

failed_open 

closed 

open 

open 

open 

open 



no 

no 

no 

no 

no 

no 

no 

yes 

no 

yes 

no 

yes 

no 

yes 

no 

no 

yes 

no 

yes 



define rule as a saved 2-dimensional text array 
define component as a pointer variable 

define index. command, total .command, number. power, total. power, 
number. process, total. process, output. strength, ruletype, 
success and j as integer variables 
define later. case as a saved integer variable 



Enter decision table. 



if later. case eg .no 

reserve rule as 16 by 4 
let rule (1,1) = 
let rule(l,3) = 
let rule (2,1) = "" 
let rule(2,3) = 
let rule(3,l) = "close" 
let rule (3, 3) = "" 
let rule (4,1) = "none" 



let rule(l,2) 
let rule (1,4) 
let rule(2,2) 
let rule(2,4) 
let rule(3,2) 
let rule (3, 4) 
let rule (4, 2) 



" f ailed_closed" 
"no" 

"closed" 

"closed" 



4 
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56 


let 


rule(4,3) = " 


" 


let 


rule (4, 4) = 


"closed" 


57 


let 


rule(5,l) = ' 


open" 


let 


rule(5,2) = 


"yes" 


58 


let 


rule(5,3) = ' 


no" 


let 


rule (5, 4) = 


"closed" 


59 


let 


rule(6,l) = ' 


open" 


let 


rule(6,2) = 


"yes" 


60 


let 


rule(6,3) = ' 


yes" 


let 


rule (6, 4) = 


"closed" 


61 


let 


rule(7,l) = ' 


" 


let 


rule(7,2) = 


nil 


62 


let 


rule(7,3) = ' 


no" 


let 


rule(7,4) = 


"failed_open' 


63 


let 


rule (8,1) = " 


" 


let 


rule(8,2) = 


II II 


64 


let 


rule(8,3) = " 


yes" 


let 


rule (8, 4) = 


"failed_open' 


65 


let 


rule(9,l) = " 


" 


let 


rule(9,2) = 


"no" 


66 


let 


rule(9,3) = " 


no" 


let 


rule(9,4) =■ 


■ "open" 


67 


let 


rule(10,l) = 


II H 


let 


rule(10,2) 


a "no" 


68 


let 


rule(10,3) = 


"yes" 


let 


rule(10,4) 


= "open" 


69 


let 


rule(ll,l) = 


"close" 


let 


rule(ll,2) 


= "yes" 


70 


let 


rule(ll,3) = 


"no" 


let 


rule(ll,4) 


= "open" 


71 


let 


rule(12,l) = 


"close" 


let 


rule(12,2) 


_ Myggll 


72 


let 


rule(12,3) = 


"yes" 


let 


rule (12, 4) 


= "open" 


73 


let 


rule(13,l) = 


"none" 


let 


rule(13,2) 


= "" 


74 


let 


rule(13,3) = 


"no" 


let 


rule(13,4) 


= "open" 


75 


let 


rule(14,l) = 


"none" 


let 


rule(14,2) 


= "" 


76 


let 


rule(14,3) = 


"yes" 


let 


rule (14,4) 


= "open" 


77 


let 


rule(15,l) = 


"open" 


let 


rule(15,2) 


= "" 


78 


let 


rule(15,3) = 


"no" 


let 


rule(15,4) 


= "open" 


79 


let 


rule(16,l) = 


"open" 


let 


rule(16,2) 


= nil 


80 

81 

82 


let 

let 

always 


rule(16,3) = 
later. case = 


"yes" 

.yes 


let 


rule(16,4) 


= "open" 



83 " 

84 '' Determine input signal status. Assume that "open" and "close" 

85 '' commands cancel each other out (respective values of 1 and -1) . 

86 " 

87 for every signal in input . sset (component) 

88 do 

89 if signal. type (signal) eq "process" 

90 add 1 to total .process 

91 if strength (signal) eq .on 

92 add 1 to number .process 

93 always 

94 else 

95 if signal. type (signal) eq "power" 

96 add 1 to total. power 

97 if strength (signal) eq .on 

98 add 1 to number. power 

99 always 

100 else 

101 add 1 to total. command 

102 add strength (signal) to index. command 

103 always 

104 always 

105 loop 

106 ' ' 

107 '' Develop test vector for comparison with rules. Assume that 

108 ' ' a single process signal is sufficient, and that a single power 

109 '' signal is sufficient (i.e., OR gates). 

110 ' ' 
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111 if index. command eq -1 

112 let test(l) = "close" 

113 else 

114 if index. command eq 0 

115 let test(l) = "none" 

116 else 

117 let test(l) =* "open" 

118 always 

119 always 

120 if number. power ge 1 

121 let test (2) •• "yes" 

122 else 

123 let test (2) - "no" 

124 always 

125 " 

126 " By changing the test for number of process inputs, it is 

127 '' possible to simulate k-out-of-n components. 

128 " 

129 if number. process ge 1 

130 let test (3) = "yes" 

131 else 

132 let test (3) = "no" 

133 always 

134 let test (4) = state (component) 

135 " 

136 " Determine appropriate rule. 

137 " 

138 for ruletype = 1 to 16 

139 do 

140 for j = 1 to 4 

141 do 

142 if rule (ruletype, j ) ne "" and rule (ruletype, j) ne test(j) 

143 go to 'next' 

144 always 

145 loop 

146 go to 'found' 

147 'next' 

148 loop 

149 " 

150 " Select rule. 

151 " 

152 'found' 

153 select case ruletype 

154 

155 case 1 

156 let state (component) = "failed_closed" 

157 let output. strength = .no 

158 

159 case 2, 3, 4 

160 let state (component) = "closed" 

161 let output. strength = .no 

162 

163 case 5 

164 call demand. test giving component yielding success 

165 if success eq .no 
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166 let state (component] = "failed_closed” 

167 let output . strength = .no 

168 else 

169 let state (component) = "open” 

170 let output. strength = .no 

171 always 

172 

173 case 6 

174 call demand. test giving component yielding success 

175 if success eq .no 

176 let state (component) = "failed_closed" 

177 let output. strength = .no 

178 else 

179 let state (component) = "open" 

180 let output. strength = .yes 

181 always 

182 

183 case 7 

184 let state (component) = "failed_open" 

185 let output. strength = .no 

186 

187 case 8 

188 let state (component) = "failed_open" 

189 let output. strength = .yes 

190 

191 case 9, 13, 15 

192 let state (component) = "open" 

193 let output. strength = .no 

194 

195 case 10, 14, 16 

196 let state (component) = "open" 

197 let output . strength = .yes 

198 

199 case 11 

200 call demand. test giving component yielding success 

201 if success eq .no 

2 02 let state (component) »• "failed_open" 

203 let output. strength => .no 

204 else 

205 let state (component) = "closed" 

206 let output. strength »» .no 

207 always 

208 

209 case 12 

210 call demand. test giving component yielding success 

211 if success eq .no 

212 let state (component) = "failed_open" 

213 let output. strength = .yes 

214 else 

215 let state (component) = "closed" 

216 let output. strength = .no 

217 always 

218 

219 default 

220 " 



Dynamic Simulation Model 



242 



221 " Error messages can be put here if rule not matched. 

222 " 

223 endselect 

224 " 

225 " Update output signals. 

226 " 

227 for every signal in output. sset (component] 

228 let strength (signal) = output. strength 

229 

230 return 

231 

232 end "valve 
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Appendix C 
TANK Progreua Listing 



V 
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1 routine flow. update given tank 

2 " 

3 " Determine the new flow rate if it has changed. 

4 " 

5 define tank as a pointer variable 

6 let flow. rate. in (tank) = 0 

7 let flow. rate. out (tank) = 0 

8 for every component in tank. input. cset (tank) 

9 do 

10 if name (component) eg "unit2" 

11 if state (component) eg "open” 

12 or state (component) eg "failed_open" 

13 add 0.01 to flow. rate. in (tank) 

14 always 

15 else 

16 if name (component) eg "unit3" 

17 if state (component) eg "open" 

18 or state (component) eg "failed_open" 

19 add 0.005 to flow. rate. in (tank) 

20 always 

21 always 

22 always 

23 loop 

24 for every component in tank. output. cset (tank) 

25 do 

26 if state (component) eg "open" 

27 or state (component) eg "failed_open" 

28 add 0.01 to flow. rate. out (tank) 

29 always 

30 loop 

31 

32 return 

33 

34 end "flow. update 




4 







1 ?* 



I I 
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1 process stop. tank 

2 ' ' 

3 ' ' This process will reset the tank process so it is ready 

4 " for the execution of another trial. 

5 " 

6 for every tank in ev.s(i.tank) 

7 do 

8 interrupt the tank 

9 loop 
10 

11 for every tank in system. tset 

12 do 

13 let level (tank) = 100.0 

14 let time. a (tank) =*0.0 

15 resume the tank 

16 loop 

17 

18 return 

19 

20 end "stop. tank 
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1 process tank 

2 " 

3 ' ' This routine will continuously monitor the water level 

4 ' ' in a tank. 

5 " 

6 'tankreset' 

7 suspend 

8 while time.v It (simulation. time 10) 

9 do 
10 ' ' 

11 " This portion of the routine determines if the tank is in the 

12 ' ' proper control region and calls the tank update routine to 

13 ' ' make changes if necessary. 

14 ' ' 

15 work continuously evaluating 'water. level ' testing 'tank. condition' 

16 let net. flow. rate(tank) = flow. rate. in (tank) - flow. rate. out (tank) 

17 if level (tank) gt 90.0 

18 go to 'tankreset' 

19 otherwise 

20 call tank. update giving tank 

21 if level (tank) gt high. level (tank) 

22 or level (tank) It low. level (tank) 

23 suspend 

24 go to 'tankreset' 

25 always 

26 

27 loop 

28 

29 suspend 

30 

31 end ' 'tank 
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function tank. condition (tank) 



This function will cause calling of the tank update 
routine if the tank status is not satisfactory. 

define tank as a pointer variable 

Use this method to adjust tank flow rate only at the 
end of integration time steps. 



define x as a real variable 

let X = flow. rate. in (tank) - flow. rate. out (tank) 
if net. flow. rate(tank) ne x 
return with 1 
otherwise 

Is the tank too full? 

if level (tank) gt high. level (tank) 
return with 1 
otherwise 

Is the tank too empty? 

if level (tank) It low. level (tank) 
return with 1 
otherwise 

Is the tank level high and the control state wrong? 

if level (tank) gt high. set (tank) 

for every component in system. cset 
do 

if name (component) eg "unitl" 

and state (component) eq "closed" 
return with 1 
otherwise 

if name (component) eq "unit2" 

and state (component) eq "open" 
return with 1 
otherwise 

if name (component) eq "unit3" 

and state (component) eq "open" 
return with 1 
otherwise 
loop 
always 



Is the tank level low and the control state wrong? 



if level (tank) It low. set (tank) 

for every component in system. cset 
do 

if name (component) eq "unitl" 

and state (component) eq "open" 
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56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90 

91 



return with 1 
otherwise 

if name (component) eg "unit2" 

and state (component) eg "closed" 
return with 1 
otherwise 

if name (component) eg "unit3" 

and state (component) eg "closed" 
return with 1 
otherwise 
loop 
always 

'' Is the tan)c level satisfactory and the control state wrong? 

if level (tan)c) le high. set (tank) 
and level (tank) ge low. set (tank) 
for every component in system. cset 
do 

if name (component) eg "unitl" 

and state (component) eg "closed" 
return with 1 
otherwise 

if name (component) eg "unit2" 

and state (component) eg "closed" 
return with 1 
otherwise 

if name (component) eg "unit3" 

and state (component) eg "open" 
return with 1 
otherwise 
loop 
always 

return with 0 
end ' 'tank. condition 
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1 routine tank. initialize. run 

2 " 

3 '' This routine initializes all of the variables associated 

4 ' ' with the Aldemir Tank Problem. Initializes for the number 

5 " of trials to be performed. 

6 " 

7 define signal. count as an integer variable 

8 let integrator. V = 'runge.kutta.r' 

9 let max. step. V = 0.04166666666667 '' Approximately 1 hour 

10 let min. step. V = 0.04166666666667 " Approximately l hour 

11 let abs.err.v = 0.001 

12 let rel.err.v = 0.1 

13 " 

14 " Create a tank. 

15 " 

16 reserve tptr(*) as l 

17 activate a tank called tptr(l) now 

18 file tptr(l) in system. tset 

19 let high. level (tptr(l) ) » 3.0 

20 let low. level (tptr(l) ) = -3.0 

21 let high.set(tptr(l) ) = 1.0 

22 let low.set(tptr(l) ) = -1.0 

23 " 

24 " Must create all of the Tank output signals since the base 

25 " program does not recognize the tank as a component. These 

26 " signals include three command signals (one to each valve), 

27 " the tank process output to the outlet valve, and the process 

28 " output signal to the system for system status checking. 

29 " 

30 let signal. count = 9 

31 create a signal called sptr( signal. count) 

32 let signal. type(sptr(slgnal. count) ) = "command" 

33 let origin(sptr(signal.count) ) = "tank" 

34 let destinatlon(sptr(signal. count) ) = "unitl" 

35 for every component in system. cset 

36 with name (component) eg "unitl" 

37 find the first case 

38 if found 

39 file sptr( signal .count) in input. sset (component) 

40 always 

41 file sptr (signal. count) in tank. output. sset ( tptr (1) ) 

42 file sptr (signal. count) in system. sset 

43 " 

44 add 1 to signal. count 

45 create a signal called sptr (signal. count) 

46 let signal. type (sptr (signal. count) ) = "command" 

47 let origin(sptr(signal.count) ) = "tank" 

48 let destination(sptr(slgnal.count) ) = "unit2" 

49 for every component in system. cset 

50 with name (component) eg "unit2" 

51 find the first case 

52 if found 

53 file sptr (signal. count) in input. sset (component) 

54 always 

55 file sptr (signal. count) in tank. output. sset(tptr(l) ) 



m 
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56 file sptr(slgnal. count) in system. sset 

57 ' ' 

58 add 1 to signal. count 

59 create a signal called sptr(signal. count) 

60 let s ignal. type (sptr( signal. count) ) = "command" 

61 let origin(sptr (signal. count) ) = "tank" 

62 let destination(sptr(signal.count) ) = "unit3" 

63 for every component in system. cset 

64 with name (component) eq "unit3" 

65 find the first case 

66 if found 

67 file sptr( signal. count) in input. sset (component) 

68 always 

69 file sptr( signal. count) in tank. output. sset(tptr(l) ) 

70 file sptr( signal. count) in system. sset 

71 " 

72 add 1 to signal. count 

73 create a signal called sptr( signal. count) 

74 let signal. type(sptr(signal. count) ) = "process" 

75 let origin(sptr (signal. count) ) = "tank" 

76 let destination(sptr(signal. count) ) = "unitl" 

77 for every component in system. cset 

78 with name (component) eq "unitl" 

79 find the first case 

80 if found 

81 file sptr( signal. count) in input . sset (component) 

82 always 

83 file sptr (signal. count) in tank. output. sset (tptr ( 1) ) 

84 file sptr(signal. count) in system. sset 

85 " 

86 add 1 to signal. count 

87 create a signal called sptr (signal . count) 

88 let s ignal. type (sptr (signal. count) ) = "process" 

89 let origin (sptr (signal. count) ) = "tank" 

90 let destination(sptr (signal. count) ) = "system" 

91 file sptr (signal. count) in tank. output. sset (tptr (1) ) 

92 file sptr (signal. count) in system. sset 

93 file sptr (signal. count) in system. success. sset 

94 for every component in system. cset 

95 do 

96 for every signal in output. sset (component) 

97 do 

98 if destination (signal) eq "tank" 

99 file signal in tank. input. sset(tptr(l) ) 

100 file component in tank. input. cset(tptr(l) ) 

101 always 

102 loop 

103 for every signal in input . sset (component) 

104 with signal. type(signal) eq "process" 

105 do 

106 if origin (signal) eq "tank" 

107 file component in tank. output. cset(tptr(l) ) 

108 always 

109 loop 

110 loop 
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111 

112 return 

113 

114 end "tank, initialize. run 
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2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 



routine tank. initialize. trial 

" This routine will reset the appropriate values to begin 
" a new trial with the tank operating correctly. 

let level (tptr(l) ) » 0.0 

let net. flow. rate(tptr(l) ) = 0.0 

for every signal in tank. output. sset(tptr(l) ) 

do 

' ' Turn on the flow output and test signal from the tank. 

if signal. type(signal) = "process" 
let strength (signal) = .on 
always 

'' Turn off the command signals for the valves to change position. 

if signal. type (signal) » "command" 
let strength (signal) = .off 
always 
loop 

return 

end ' 'tank. initialize. trial 
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1 routine tank. update given tank 

2 " 

3 " This routine determines the flow going in and out of the 

4 ' ' tank and controls the opening and closing of the inlet and 

5 " outlet valves. If the tank should happen to dryout or over 

6 '' flow this routine will suspend the tank routine. 

7 " 

8 define tank as a pointer variable 

9 " 

10 " This is to track dryout. 

11 " 

12 if level (tank) It low. level (tank) 

13 '' for every signal in tank. output. sset (tank) 

14 '' with signal .type (signal) eq "process" 

15 " do 

16 '' let strength (signal) = .no 

17 ' ' loop 

18 go to 'leave' 

19 otherwise 

20 " 

21 " This is to track overflow. 

22 " 

23 if level (tank) gt high. level (tank) 

24 for every signal in tank. output. sset (tank) 

25 with destination (signal) eq "system" 

2 6 do 

27 let strength (signal) = .no 

28 loop 

29 go to 'leave' 

30 otherwise 

31 if level (tank) It low.set(tank) 

32 " 

33 " Close the outlet valve and open both inlet valves. 

34 " 

35 for every component in tank. output. cset (tank) 

3 6 do 

37 for every signal in input. sset (component) 

38 with signal. type (signal) eq "command" 

3 9 do 

40 let strength (signal) = -1 

41 loop 

42 loop 

43 for every component in tank. input. cset (tank) 

44 do 

45 for every signal in input. sset (component) 

46 with signal. type (signal) eq "command" 

47 do 

48 let strength (signal) = 1 

49 loop 

50 loop 

51 go to 'leave' 

52 otherwise 

53 if level (tank) gt high. set (tank) 

54 " 

55 " Open the outlet valve and close both inlet valves. 
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56 " 

57 for every component in tank. output. cset (tank) 

58 do 

59 for every signal in input . sset (component) 

60 with signal. type (signal) eq "command" 

61 do 

62 let strength (signal) = 1 

63 loop 

64 loop 

65 for every component in tank. input. cset (tank) 

66 do 

67 for every signal in input. sset (component) 

68 with signal. type (signal) eq "command" 

69 do 

70 let strength (signal) - -1 

71 loop 

72 loop 

73 go to 'leave' 

74 otherwise 

75 " 

76 " If the level of the tank is in the operating range, 

77 " open the outlet valve (unitl) and the inlet valve from 

78 '' unit2, but close the inlet valve from unit3. 

79 " 

80 for every component in tank. output. cset (tank) 

81 do 

82 for every signal in input. sset (component) 

83 with signal. type(signal) eq "command" 

84 do 

85 let strength(signal) = 1 

86 loop 

87 loop 

88 for every component in tank. input. cset (tank) 

89 do 

90 if name (component) eq "unit2" 

91 for every signal in input. sset (component) 

92 with signal. type (signal) eq "command" 

93 do 

94 let strength (signal) = 1 

95 loop 

96 else 

97 if name (component) eq "unit3" 

98 for every signal in input. sset (component) 

99 with signal. type(signal) eq "command" 

100 do 

101 let strength (signal) = -1 

102 loop 

103 always 

104 always 

105 loop 

106 'leave' 

107 call system. update 

108 return 

109 

110 end "tank. update 



,!|r 
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1 routine water. level (tank) 

2 " 

3 ' ' This routine supplies the integration rule for the continuous 

4 ' ' variable level of the tank. 

5 " 

6 define tank as a pointer variable 

7 let d. level (tank) = net. flow. rate(tank) *1440. 0 

8 " 

9 " We have left the time step as days and are reading flow rates 

10 " as meter level change per minute thus the factor of 1440 above. 

11 " 

12 end "water. level 
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Appendix D 
Seuaple Input Files 
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COMPONENT passive operating 

0.0 0.01 

1.0 100.0 1.0 

system process 
system process 

standby 



Type of run (0 for normal) 
Number of trials 
Number of time points 
Type of time distribution 
Number of components 
Component one 
Failure data 
Repair data 
Input signal 
Output signal 
Initial system state 
System success criteria 
Number of external events 
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PUMPl active operating 

0.0 0.01 

1.0 100.0 1.0 

system power 

system command 

system process 

VALVE process 

PUMP2 active operating 

0.0 0.01 

1.0 100.0 1.0 

system power 

system command 

system process 

VALVE process 

PUMPl active operating 

0.0 0.01 

1.0 100.0 1.0 

system power 

system command 

system process 

VALVE process 

VALVE valve open 

0.0 0.01 

1.0 100.0 1.0 

■ system power 

system command 

PUMPl process 

PUMP2 process 

PUMPl process 

system process 

standby 



, FAILURE AND REPAIR. 

Time of simulation 
Type of run (0 for normal) 
Number of trials 
Number of time points 
Type of time distribution 
Number of components 
1 Component one 
Failure data 
Repair data 
Input signal 
Input signal 
Input signal 
Output signal 
1 1 Component two 

Failure data 
Repair data 
Input signal 
Input signal 
Input signal 
Output signal 
I 1 Component three 

Failure data 
Repair data 
Input signal 
Input signal 
Input signal 
Output signal 
) 1 Component four 

Failure data 
Repair data 
L Input signal 

L Input signal 

L Input signal 

L Input signal 

L Input signal 

L Output signal 

Initial system state 
System success criteria 
Number of external events 
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SIMULATION OF GO-FLOW LIGHT BULB PROBLEM 
20.00 
0 

1000 

7 

0 

0.00 

1.00 

9.99 

10.00 

11.00 

15.00 

20.00 

5 

BATTERY passive standby 1 2 

0.1 0.0 



system 

SWITCHl 

SWITCH2 

SWITCHl switch 

0.3 0. 



process 

process 

process 

open 



0 

0 

0 



system command 

system power 

BATTERY process 

LIGHTl process 

SWITCH2 switch open 

0.3 0.0 




system command 

system power 

BATTERY process 

LIGHT2 process 

LIGHTl passive standby 

0.2 0.001 



0 

1 

0 

0 

1 1 



SWITCHl process 0 

system process 0 

LIGHT2 passive standby 1 1 

0.2 0.001 



SWITCH2 

system 

standby 

1 

3 

0.00 

1 

system BATTERY 

1 

0.00 

1 

system SWITCHl 



process 

process 



0 



process 



0 



command 



10.00 

1 

system SWITCH2 



0 



command 



0 

0 



Time of simulation 
Type of run (0 for normal) 
Number of trials 
Number of time points 
Type of time distribution 



Time points 



Number of components 

Component number one 

Failure data 

Repair data 

Input signal 

Output signal 

Output signal 

Component number two 

Failure data 

Repair data 

Input signal 

Input signal 

Input signal 

Output signal 

Component number three 

Failure data 

Repair data 

Input signal 

Input signal 

Input signal 

Output signal 

Component number four 

Failure data 

Repair data 

Input signal 

Output signal 

Component number five 

Failure data 

Repair data 

Input signal 

Output signal 

Initial system state 

System success criteria 

Number of external events 

External event §1, Time, #Comps. 

Number signals 

Signal 

New strength 

External event §2, Time, #Comps. 

Number signals 

Signal 

New strength 

External event #3, Time, jfComps. 

Number signals 

Signal 

New strength 
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TEST OF THE TANK PORTION OF THE PROGRAM 
1000.00 
0 

1000 

201 

1 

3 

unitl 



unit2 



valve 


open 


3 


0.0 0.00312 




1.0 


1.0 0.0 




system 


power 


1 


tank 


process 


1 


tank 


command 


1 


nowhere 


process 


1 


valve 


open 


3 


0.0 0.00456 




1.0 


1.0 0.0 




system 


power 


1 


system 


process 


1 


tank 


command 


1 


tank 


process 


1 


valve 


closed 


3 


0.0 0.0057 




1.0 


1.0 0.0 




system 


power 


1 


system 


process 


1 


tank 


command 


-1 


tank 


process 


0 



standby 

1 

0 
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Appendix E 
Scuaple Output Files 
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SINGLE COMPONENT, EXP REPAIR AND FAILURE, DUAL REPAIR STATES 
10000.00 
0 

100 

21 

1 

1 

COMPONENT passive operating 1 1 

0 . .01000 
1.00000 100.00000 1.00000 

system process 1 

system process 1 

standby 

1 

0 
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AFTER 100 TRIALS 
AND 

OVER A TIME PERIOD OF 10000 HOURS 
THE AVERAGE SYSTEM UNAVAILABILITY IS AS FOLLOWS 

The minimum is: .5510 

The 1st percentile is: .5510 

The 5th percentile is: .5804 

The 25th percentile is: .6343 

The 40th percentile is: .6538 

The 50th percentile is: .6618 

The 60th percentile is: .6740 

The 75th percentile is: .7002 

The 95th percentile is: .7440 

The 99th percentile is: .7579 

The maximum is: .7732 

The mean is: .6644 

The variance is: .0023 
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AFTER 100 TRIALS 

THE TIME DEPENDENT UNAVAILABILITY IS AS FOLLOWS 
TIME UNAVAILABILITY 



0. 


0. 


500.00 


.6300 


1000.00 


.7000 


1500.00 


.7000 


2000.00 


.6800 


2500.00 


.6700 


3000.00 


.6500 


3500.00 


.6700 


4000.00 


.7200 


4500.00 


.6900 


5000.00 


.6400 


5500.00 


.5900 


6000.00 


.6300 


6500.00 


. 6800 


7000.00 


.6500 


7500.00 


. 6800 


8000.00 


.6900 


8500.00 


.6800 


9000.00 


.6100 


9500.00 


.7000 


10000.00 


.6400 
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point 


1 


is 


.5510 


point 


2 


is 


.5622 


point 


3 


is 


.5700 


point 


4 


is 


.5787 


point 


5 


is 


.5804 


point 


6 


is 


.5836 


point 


7 


is 


.5883 


point 


8 


is 


.5956 


point 


9 


is 


.5962 


point 


10 


is 


.5967 


point 


11 


is 


.5976 


point 


12 


is 


.5997 


point 


13 


is 


.6006 


point 


14 


is 


.6056 


point 


15 


is 


. 6095 


point 


16 


is 


.6121 


point 


17 


is 


.6122 


point 


18 


is 


.6167 


point 


19 


is 


.6179 


point 


20 


is 


.6223 


point 


21 


is 


.6233 


point 


22 


is 


. 6264 


point 


23 


is 


.6321 


point 


24 


is 


.6342 


point 


25 


is 


. 6343 


point 


26 


is 


. 6371 


point 


27 


is 


. 6374 


point 


28 


is 


.6399 


point 


29 


is 


.6414 


point 


30 


is 


.6430 


point 


31 


is 


.6444 


point 


32 


is 


.6454 


point 


33 


is 


. 6464 


point 


34 


is 


.6465 


point 


35 


is 


.6477 


point 


36 


is 


.6481 


point 


37 


is 


.6494 


point 


38 


is 


.6500 


point 


39 


is 


.6525 


point 


40 


is 


.6538 


point 


41 


is 


.6540 


point 


42 


is 


.'6544 


point 


43 


is 


.6547 


point 


44 


is 


.6555 


point 


45 


is 


.6568 


point 


46 


is 


.6586 


point 


47 


is 


.6597 


point 


48 


is 


.6617 


point 


49 


is 


.6617 


point 


50 


is 


.6618 


point 


51 


is 


.6620 


point 


52 


is 


.6626 


point 


53 


is 


.6633 



1 



f 
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point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 

point 



54 


is 


55 


is 


56 


is 


57 


is 


58 


is 


59 


is 


60 


is 


61 


is 


62 


is 


63 


is 


64 


is 


65 


is 


66 


is 


67 


is 


68 


is 


69 


is 


70 


is 


71 


is 


72 


is 


73 


is 


74 


is 


75 


is 


76 


is 


77 


is 


78 


is 


79 


is 


80 


is 


81 


is 


82 


is 


83 


is 


84 


is 


85 


is 


86 


is 


87 


is 


88 


is 


89 


is 


90 


is 


91 


is 


92 


is 


93 


is 


94 


is 


95 


is 


96 


is 


97 


is 


98 


is 


99 


is 


100 


is 



.6647 

.6661 

.6671 

.6674 

.6680 

.6694 

.6740 

.6742 

.6756 

.6763 

.6821 

.6835 

.6850 

.6875 

.6876 

.6879 

.6922 

.6932 

.6967 

.6978 

.6996 

.7002 

.7023 

.7040 

.7049 

.7064 

.7064 

.7084 

.7085 

.7097 

.7136 

.7146 

.7180 

.7185 

.7218 

.7243 

.7248 

.7260 

.7273 

.7375 

.7416 

.7440 

.7502 

.7523 

.7541 

.7579 

.7732 
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SIMULATION OF GO-FLOW LIGHT BULB PROBLEM 
20.00 
0 

1000 

7 

0 

0 . 

1.00 

9.99 

10.00 

11.00 

15.00 

20.00 



5 



BATTERY passive 


standby 


1 


2 


.10000 0. 








1.00000 l.OOOOC 


1 0. 






system 


process 


0 




SWITCHl 


process 


0 




SWITCH2 


process 


0 




SWITCHl switch 


open 


3 


1 


.30000 0. 








1.00000 l.OOOOC 


1 0. 






system 


command 


0 




system 


power 


1 




BATTERY 


process 


0 




LIGHTl 


process 


0 




SWITCH2 switch 


open 


3 


1 


.30000 0. 








1.00000 l.OOOOC 


1 0. 






system 


command 


0 




system 


power 


1 




BATTERY 


process 


0 




LIGHT2 


process 


0 




LIGHTl passive 


standby 


1 


1 


.20000 .00100 






1.00000 1.00000 0. 






SWITCHl 


process 


0 




system 


process 


0 




LIGHT2 passive 


standby 


1 


1 


.20000 .00100 






1.00000 l.OOOOC 


1 0. 






SWITCH2 


process 


0 




system 


process 


0 





standby 

1 

3 



0 . 0 

1 

system BATTERY process 
1 



0 



1 



0 
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system SWITCHl 

-1 

10.00 

1 

system SWITCH2 

-1 



command 

0 

command 









i 
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AFTER 


1000 TRIALS 


THE TIME DEPENDENT 


UNAVAILABILITY IS AS FOLLOWS 


TIME 


UNAVAILABILITY 


0. 

1.00 

9.99 

10.00 

11.00 

15.00 

20.00 


.5090 

.5090 

.5120 

.2940 

.2940 

.2990 

.3020 
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AFTER 1000 TRIALS 
AND 

OVER A TIME PERIOD OF 20 HOURS 
THE AVERAGE SYSTEM UNAVAILABILITY IS AS FOLLOWS 



The 


minimum is: 




.0000 


The 


1st percentile is: 


.0000 


The 


5th percentile is: 


.0000 


The 


25th percentile 


is: 


.0000 


The 


40th percentile 


is: 


. 0000 


The 


50th percentile 


is: 


. 0044 


The 


60th percentile 


is: 


.0492 


The 


75th percentile 


is: 


1.0000 


The 


95th percentile 


is: 


1.0000 


The 


99th percentile 


is: 


1.0000 


The 


maximum is: 




1.0000 


The 


mean is: 




.3416 


The 


variance is: 




.2024 
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SIMULATION OF GO-FLOW LIGHT BULB PROBLEM 

20.00 

0 

10000 

7 

0 

0 . 

1.00 

9.99 
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11.00 

15.00 
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1 


.30000 0. 

1.00000 1.00000 0. 


system command 
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0 
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0 




SWITCH2 switch open 


3 


1 


.30000 0. 

1.00000 1.00000 0. 


system command 
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system power 


1 




BATTERY process 


0 




LIGHT2 process 
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1 


1 
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1.00000 1.00000 0. 


SWITCHl process 


0 




system process 
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LIGHT2 passive standby 
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1.00000 1.00000 0. 


SWITCH2 process 


0 




system process 
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system SWITCHl 

-1 
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1 

system SWITCH2 

-1 



command 

0 

command 
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AFTERIOOOO TRIALS 



THE TIME DEPENDENT 


UNAVAILABILITY IS AS FOLLOWS 


TIME 


UNAVAILABILITY 


0. 

1.00 

9.99 

10.00 

11.00 

15.00 

20.00 


.4993 
.4999 
.5052 
.2757 
. 2763 
. 2787 
.2814 
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AFTERIOOOO TRIALS 
AND 

OVER A TIME PERIOD OF 20 HOURS 
THE AVERAGE SYSTEM UNAVAILABILITY IS AS FOLLOWS 



The 


minimum is: 




. 0000 


The 


1st percentile is: 


. 0000 


The 


5th percentile is: 


.0000 


The 


25th percentile 


is: 


. 0000 


The 


40th percentile 


is: 


.0000 


The 


50th percentile 


is: 


.0033 


The 


60th percentile 


is: 


.0289 


The 


75th percentile 


is: 


1.0000 


The 


95th percentile 


is: 


1.0000 


The 


99th percentile 


is : 


1.0000 


The 


maximum is: 




1.0000 


The 


mean is: 




. 3225 


The 


variance is: 




. 1944 
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TEST OF THE TANK PORTION OF THE PROGRAM 
1000.00 
0 
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1 

3 
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0.0 0.00312 

1.0 1.0 0.0 

system power 1 
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unit2 valve open 3 1 

0.0 0.00456 

1.0 1.0 0.0 
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system process 1 
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tank process 1 

unit3 valve closed 3 1 

0.0 0.0057 

1.0 1.0 0.0 
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system process 
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tank process 
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-1 

0 



Dynamic Simulation Model 



lie 



AFTER 1000 TRIALS 

THE TIME DEPENDENT UNAVAILABILITY ANALYSIS IS AS FOLLOWS 
TIME UNAVAILABILITY 



0 . 

5.00 

10.00 

15.00 

20.00 

25.00 

30.00 

35.00 

40.00 

45.00 

50.00 

55.00 

60.00 

65.00 

70.00 

75.00 

80.00 

85.00 

90.00 

95.00 

100.00 

105.00 

110.00 

115.00 

120.00 

125.00 

130.00 

135.00 

140.00 

145.00 

150.00 

155.00 

160.00 

165.00 

170.00 

175.00 

180.00 

185.00 

190.00 

195.00 

200.00 

205.00 

210.00 

215.00 

220.00 

225.00 

230.00 

235.00 

240.00 

245.00 

250.00 



0 . 

0 . 

0 . 

0 . 

0 . 

.0010 
.0010 
.0040 
.0060 
.0090 
.0120 
.0130 
.0140 
.0160 
.0170 
.0200 
.0230 
.0240 
.0270 
.0300 
.0320 
.0330 
.0370 
.0400 
.0430 
.0460 
.0510 
.0580 
.0640 
.0690 
.0720 
.0740 
.0740 
.0760 
.0780 
.0830 
.0870 
.0870 
.0880 
.0920 
. 0940 
.0950 
. 1010 
. 1020 
. 1120 
. 1160 
. 1180 
. 1210 
. 1230 
.1260 
. 1300 
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255.00 

260.00 

265.00 

270.00 

275.00 

280.00 

285.00 

290.00 

295.00 

300.00 

305.00 

310.00 

315.00 

320.00 

325.00 

330.00 

335.00 

340.00 

345.00 

350.00 

355.00 

360.00 

365.00 

370.00 

375.00 

380.00 

385.00 

390.00 

395.00 

400.00 
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410.00 

415.00 

420.00 

425.00 

430.00 

435.00 

440.00 

445.00 

450.00 

455.00 

460.00 

465.00 

470.00 

475.00 

480.00 

485.00 

490.00 

495.00 

500. 00 

505.00 

510.00 

515.00 

520.00 



. 1350 
.1390 
.1430 
.1440 
.1500 
.1560 
. 1570 
. 1590 
. 1630 
.1650 
.1670 
.1730 
. 1770 
. 1790 
.1800 
.1810 
.1830 
.1850 
. 1850 
.1860 
.1890 
.1900 
.1920 
.1940 
.1970 
.2010 
.2020 
.2070 
.2100 
.2100 
.2100 
.2120 
.2140 
.2150 
.2170 
.2190 
.2210 
.2220 
.2240 
.2280 
.2290 
.2300 
.2340 
.2370 
.2370 
.2370 
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.2420 
.2420 
.2430 
.2470 
.2480 
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.2560 
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660.00 


.2940 


665.00 


.2940 


670.00 


.2950 


675.00 


.2970 


680.00 


.2990 


685.00 
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690.00 


.3020 


695.00 


.3060 


700.00 


.3070 


705.00 


.3090 


710.00 


.3090 


715.00 


.3090 


720.00 


.3090 


725.00 


.3100 


730.00 


.3100 


735.00 


.3110 


740.00 


.3130 


745.00 


.3160 


750.00 
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755.00 
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760.00 
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765.00 


. 3200 


770.00 
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. 3210 
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. 3210 
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.3210 
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795.00 


.3220 
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.3220 
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805.00 


.3230 


810.00 


.3240 


815.00 


.3240 


820.00 


.3250 


825.00 


.3250 


830.00 


.3250 


835.00 


.3250 


840.00 


.3260 


845.00 


.3260 


850.00 


.3260 


855.00 


.3260 


860.00 


.3260 


865.00 


.3260 
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.3350 
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AFTER 1000 TRIALS 

THE UNAVAILABILITY DISTRIBUTION DATA IS AS FOLLOWS 

The minimum is: .0000 

The 1st percentile is: .0000 

The 5th percentile is; .0000 

The 25th percentile is; .0000 

The 40th percentile is; .0000 

The median is; .0000 

The mean is; .2155 

The 60th percentile is; .0000 

The 75th percentile is: .4840 

The 95th percentile is; .8701 

The 99th percentile is; .9540 

The maximum is; .9790 

The variance is; .1085 
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Deoss 

A simulation model for 
dynamic system availabi- 
lity analysis. 
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Deoss 

A simulation model for 
dynamic system availabi- 
lity analysis. 



